Дункан Эппинг написал интересный пост.

Начиная с обновления VMware vSphere 8.0 Update 2, поддержка опции "None - Stretched Cluster" в политике хранения (Storage Policy) для конфигурации vSAN Stretched Cluster была удалена. Причина этого заключается в том, что данная опция часто приводила к ситуациям, когда клиенты ошибочно ее использовали, и при сбое обнаруживали, что некоторые виртуальные машины перестали работать.

Причиной остановки работы виртуальных машин было то, что в соответствии с этой политикой все компоненты объекта размещались в одном месте, но не было гарантии, что все объекты одной виртуальной машины будут находиться на одном сайте. Таким образом, могла возникнуть ситуация, показанная ниже, когда виртуальная машина работает на сайте B, один из ее объектов данных хранится на сайте A, другой объект данных на сайте B, и, кроме того, свидетель также находится в сайте B. К сожалению, у некоторых клиентов это приводило к странному поведению, если возникали проблемы с сетью между Сайтами A и B.

Поэтому данную опцию было решено убрать.

Одним из самых больших препятствий в управлении инфраструктурой частного облака является координация с владельцами приложений для планирования временных окон обслуживания, которые соответствуют потребностям их бизнеса. К счастью, VMware vSphere с возможностями живой миграции vMotion и Storage vMotion предлагает решение этой проблемы, обеспечивая проверенные обновления инфраструктуры без простоев. Однако, даже с преимуществами vMotion, бизнес-политики могут всё равно диктовать время и выполнение определённых операций, подчёркивая необходимость минимизировать количество операций по обслуживанию, где это возможно. Уменьшая число таких операций, ИТ-команды могут минимизировать сбои, снизить затраты и повысить общую эффективность инфраструктуры.

Обновление и патчинг в одном рабочем процессе

Одним из ключевых улучшений в VMware Cloud Foundation 5.2 является новая функция под названием «Flexible Bill of Materials (BOM)», которая позволяет выбирать конкретные версии отдельных компонентов во время обновления домена рабочих нагрузок (workload domain). Это упрощает процесс обновления, сокращая количество операций по обслуживанию и минимизируя простои. В предыдущих версиях VCF процесс требовал двух операций обслуживания: одной для обновления и второй для применения асинхронного патча. Теперь же гибкий BOM в VCF 5.2 упрощает процесс, снижая административную нагрузку и потенциальные риски.

Выглядит это следующим образом (кликните на картинку, чтобы открыть анимацию):

Теперь во время процесса обновления администраторам VCF предоставляется возможность выбрать другую целевую версию компонента. Если доступны, они могут выбрать из дополнительных версий, известных как асинхронные патчи – обновления, выпущенные отдельно от списка компонентов (BOM), которые можно применить, обеспечивая большую гибкость в процессе обновления. Применимость этих асинхронных патчей определяется автоматически на основе метаданных, полученных из онлайн-репозитория. Это гарантирует, что администратору будут предложены только совместимые и актуальные патчи.

Также на эту тему есть хорошее обзорное видео от VMware:

Улучшения VCF 5.2 в управлении жизненным циклом

Помимо опции гибкого списка компонентов (BOM), VCF 5.2 вводит несколько других улучшений, упрощающих процесс обновления и развертывания. Например, администраторы VCF теперь могут применять асинхронные патчи напрямую через интерфейс SDDC Manager, что упрощает поддержание актуальности среды. Процесс развертывания доменов рабочих нагрузок также был оптимизирован: асинхронные патчи автоматически включаются, чтобы обеспечить более безопасные и актуальные новые развертывания.

VCF 5.2 также вводит новый масштабируемый подход к зеркалированию онлайн-хранилища на локальный сервер, обеспечивая легкий доступ к последним патчам и обновлениям даже в изолированных или автономных средах. Эта функция особенно полезна для организаций с жесткими требованиями безопасности или ограниченным доступом к интернету, так как она гарантирует, что последние патчи и обновления всегда доступны для развертывания.

На конференции VMware Explore 2024, вместе с презентацией новой версии платформы VMware Cloud Foundation 9, Broadcom также объявила о планах разработки следующего поколения VMware vSphere Virtual Volumes (vVols). Следующее поколение vVols будет преследовать три основные цели: обеспечить согласованный и оптимизированный пользовательский опыт на разных платформах хранения, адаптировать vVols для современных масштабируемых задач, таких как рабочие нагрузки AI/ML и развёртывания облачных провайдеров, а также полностью интегрироваться с VMware Cloud Foundation (VCF).

vVols использует управление на основе политик хранилищ (Storage Policy-Based Management, SPBM) для оптимизации операций и минимизации потребности в специализированных навыках для работы с инфраструктурой хранения. vVols устраняет необходимость в ручном предоставлении хранилища, заменяя это описательными политиками на уровне ВМ или VMDK, которые могут быть применены или обновлены через простой рабочий процесс.

Клиенты продолжают активно внедрять VMware Cloud Foundation, и они хотят интегрировать свои существующие решения для хранения в VCF, чтобы максимизировать свою отдачу от инвестиций. Они стремятся начать путь к полностью программно-определяемому подходу к инфраструктуре, упрощая операции хранения и интегрируясь с облачными возможностями управления, встроенными в частную облачную платформу VCF. По мере того, как клиенты запускают всё больше рабочих нагрузок на массивы, поддерживающие vVols, требования к производительности, масштабу и защите данных продолжают расти, поэтому vVols должен развиваться, чтобы удовлетворять эти потребности.

Планируемые преимущества следующего поколения vVols для клиентов включают:

• Полная интеграция с VMware Cloud Foundation: установка, развертывание и управление хранилищем с VCF, пригодность для использования в качестве основного и дополнительного хранилища для всех доменов рабочих нагрузок.
• Прописанная модель VASA для обеспечения согласованного и оптимизированного пользовательского опыта на всех платформах хранения.
• Поддержка масштабируемых сценариев использования для облаков.
• Обеспечение высокой доступности и развертывания с растянутыми кластерами.
• Бесшовная миграция с платформы vVols без простоев.
• Масштабируемые, неизменяемые снимки (immutable snapshots) как для традиционных, так и для современных приложений.

Для получения дополнительной информации о планируемых нововведениях vSAN и vVols рекомендуем посмотреть записи вот этих сессий VMware Explore 2024:

• VMware’s Vision for Storage and Data Protection in VMware Cloud Foundation [VCFB2086LV]
• What’s New with vSAN and Storage Operations in VMware Cloud Foundation [VCFB2085LV]
• vVols and Stretched Clusters with Pure Storage and VMware [VCFB2397LVS]
• Workload Provisioning And Protection Made Easy With VMware And NetApp [VCFB2433LVS]

Платформа VMware vSAN 8 Express Storage Architecture (ESA), работающая на процессорах Intel Xeon Scalable 4-го поколения, представляет собой современное решение для гиперконвергентной инфраструктуры (HCI), способствующее консолидации серверов и поддержке высокопроизводительных рабочих нагрузок, включая ИИ.

Недавно был выпущен документ "VMware vSAN 8 Express Storage Architecture on Intel Fourth Generation Xeon Scalable Processors", в котором рассказывается о преимуществах использования архитектуры vSAN 8 ESA на Intel Xeon Gen 4:

Преимущества работы vSAN 8 ESA на Intel Xeon 4 поколения

• Оптимизация хранения: в отличие от двухуровневой архитектуры предыдущих версий, ESA использует одноуровневую систему с NVMe-накопителями на базе TLC флэш-памяти, что позволяет увеличить емкость и производительность хранилища. Это снижает расходы на хранение данных, благодаря более эффективной компрессии данных и встроенной системе снапшотов.
• Скорость и производительность: VMware vSAN 8 ESA, в сочетании с Intel Xeon 4, значительно ускоряет работу как традиционных, так и современных приложений. Интеграция с новейшими технологиями Intel, такими как AMX (Advanced Matrix Extensions) и AVX-512 (Advanced Vector Extensions), увеличивает количество транзакций и снижает время отклика при обработке больших данных.
• Снижение задержек и повышение производительности: в тестах ESA показала до 6.2-кратного роста производительности и до 7.1-кратного снижения задержек по сравнению с предыдущими поколениями vSAN и Intel Xeon. Это позволяет консолидировать критически важные рабочие нагрузки, такие как базы данных SQL и VDI, без снижения производительности.

Поддержка AI и современных рабочих нагрузок

Для обеспечения поддержки AI-приложений, vSAN 8 ESA, благодаря новейшим процессорам Intel Xeon, справляется с обработкой больших объемов данных, необходимых для глубокого обучения и инференса, особенно в задачах классификации изображений и обработки естественного языка. Тесты показали до 9-кратного увеличения производительности при использовании INT8 в задачах машинного обучения.

Снижение затрат и повышение эффективности

За счет высокой плотности виртуальных машин и оптимизированного использования ресурсов, VMware vSAN 8 ESA позволяет сократить инфраструктурные расходы, связанные с оборудованием и энергопотреблением. Использование RAID-6 на уровне кластера с производительностью RAID-1 повышает надежность и безопасность данных без ущерба для производительности.

Заключение

VMware vSAN 8 ESA, в сочетании с процессорами Intel Xeon четвертого поколения, представляет собой мощное и экономичное решение для поддержки как традиционных, так и современных рабочих нагрузок, включая AI-приложения. Это позволяет компаниям модернизировать свою инфраструктуру, улучшить производительность и оптимизировать использование ресурсов, что особенно важно в условиях сокращающихся ИТ-бюджетов и растущих требований к производительности приложений.

Стратегии защиты данных часто включают снапшоты в той или иной форме. Они могут быть важной частью комплексной стратегии защиты данных 3-2-1, а также дополнять официальные практики защиты данных, делая операции восстановления более удобными. Однако снапшоты могут создавать технические проблемы и ограничения, которые влияют на их использование в производственных средах.

С выпуском VMware vSAN 8 U3 в составе Cloud Foundation 5.2, компания VMware представила защиту данных vSAN. Основанная на революционной архитектуре vSAN Express Storage Architecture (ESA), она представляет собой значительное изменение в способности клиентов защищать, восстанавливать и клонировать виртуальные машины с использованием знакомого им программного обеспечения.

Новые возможности с улучшенными снапшотами

Основа защиты данных vSAN заключается в механизме создания снапшотов, представленного в составе vSAN ESA. Дизайн vSAN ESA позволил инженерам разработать совершенно новый механизм создания снапшотов с нуля, отказавшись от старого подхода на основе redo-log, который использовался в оригинальной архитектуре хранения данных. Новый механизм создания снапшотов в vSAN ESA основан на запатентованной лог-структурированной файловой системе (LFS) и высокоэффективных структурах метаданных.

Различные формы лог-структурированных файловых систем широко распространены сегодня, но VMware имеет уникальную историю с этой технологией, так как Мендель Розенблюм, соучредитель VMware, первым внедрил лог-структурированную файловую систему еще в 1992 году. Файловая система LFS в vSAN новаторская по нескольким направлениям. Она реализована на основе объектов, что позволяет добиться более тонкого уровня управления по сравнению с монолитными подходами. Она также распределенная, что обеспечивает масштабируемость и гибкость, обычно ассоциируемые с распределенными системами.

Механизм создания снапшотов в vSAN ESA позволяет хранить снапшоты практически без потери производительности. Преимущества аналогичны снапшотам на основе массивов (storage-based snapshots), которые часто хвалят за их эффективность и производительность. Но снапшоты vSAN ESA имеют некоторые отличительные преимущества перед снапшотами на основе массивов, которые существенно влияют на их полезность в производственной среде.

Проблемы снапшотов на основе массивов

Наиболее распространенный способ представления ресурсов емкости в хранилищах — через тома LUN. В сочетании с кластерной файловой системой, такой как VMFS, это позволяет разместить десятки или сотни различных ВМ и их файлов на одном LUN для использования хостами vSphere, подключенными к хранилищу данных. Хотя это работало достаточно хорошо в течение многих лет, но у этого подхода есть некоторые присущие проблемы.

1. Единица управления. Хотя вас могут интересовать несколько конкретных ВМ в LUN, массив рассматривает данные в LUN целиком. Снапшот на основе массива захватывает все измененные данные в LUN, включая ВМ, которые вы, возможно, не хотели бы захватывать. Это может увеличить потребление емкости и усложнить восстановление.

2. Создание и координация снапшотов. Неестественная единица управления, предоставляемая LUN, — это лишь часть проблемы при создании снапшотов. Механизмы создания снапшотов на основе массива не имеют осведомленности о самой ВМ или о том, когда операции ввода-вывода инициированы ВМ. Дополнительные операции могут потребоваться для захвата снимка всего LUN, чтобы ввод-вывод сохранялся в согласованном состоянии. Это означает, что в зависимости от обстоятельств гипервизор может приостанавливать каждую ВМ, использующую этот LUN, чтобы массив мог захватить ВМ в согласованном состоянии. Это требует времени и точной координации.

3. Восстановление снапшотов. Восстановление ВМ до предыдущего состояния с использованием снапшота на основе массива обычно включает несколько шагов для временного представления LUN хостам без вмешательства в существующие ВМ. Текущую ВМ нужно удалить, а старую ВМ скопировать в новое место и перерегистрировать в vCenter Server, после чего отсоединить временный LUN и выполнить другие операции очистки. Это процесс, который может быть трудоемким и подверженным ошибкам.

Привязка к LUN и отсутствие осведомленности об операциях ввода-вывода ВМ часто приводят к увеличению сложности операций. vSAN решает задачу создания снапшотов более эффективным способом.

Более эффективный подход к созданию снимков данных

Снимки в vSAN ESA обладают возможностями, аналогичными снапшотам на основе массивов, но без многих проблем. Как отмечено в посте vSAN Objects and Components Revisited, vSAN хранит данные, аналогичные объектному хранилищу. vSAN использует набор отдельных объектов, представляющих аспекты ВМ, такие как виртуальные диски (VMDK). Эта меньшая гранулярность данных в vSAN обеспечивает лучшую доступность, масштабируемость и управление. Но эта модель имеет значительное преимущество при создании снапшотов ВМ.

Единица управления: снапшоты ESA создаются для каждой ВМ. Пользователи сфокусированы именно на машинах, поэтому имеет смысл делать это таким образом. При создании снимков ESA изменения, отслеживаемые после создания снапшота, касаются только ВМ с этим снапшотом.

Создание и координация снапшотов: поскольку vSAN является частью гипервизора, он полностью видит и контролирует путь данных ВМ. Это позволяет механизму создания снапшотов создавать их, гарантируя, что данные фиксируются в состоянии согласованности после сбоя без остановки ВМ. Это быстро и совершенно прозрачно для пользователя.

Восстановление снапшотов: независимо от того, восстанавливаете ли вы существующую ВМ на предыдущий момент времени или восстанавливаете удаленную ВМ, процесс восстановления прост и интуитивно понятен. Восстанавливайте ВМ легко прямо в интерфейсе vSphere в vCenter Server.

Снапшоты, выполненные на уровне ВМ, являются более значимой единицей управления для клиентов. Этот подход не только более интуитивен, но и намного эффективнее, так как делает снапшоты только тех ВМ, которые вам нужны, а не всё на томе LUN.

Лучший подход к защите данных

Однако быстрый и масштабируемый механизм создания снапшотов был недостаточным. Клиенты хотели использовать снапшоты для восстановления и манипуляции данными, а также планировать задачи и сохранять снапшоты автоматически. Они хотели сделать это легко и интегрировать со средствами vCenter Server. Это то, что VMware реализовала в vSAN Data Protection.

Защита данных vSAN предоставляет клиентам то, что они всегда хотели

Легкий в использовании, эффективный и интегрированный способ защиты данных, встроенный в уже известное программное обеспечение. VMware не только достигли этого, но и благодаря архитектуре внедрили инновации, делающие его удобным и гибким.

Экстремально быстрые операции

Cнапшоты на уровне ВМ делают операции простыми и быстрыми. vSAN контролирует ввод-вывод по всей цепочке, минимизируя задержки при создании и восстановлении снимков.

Масштабируемость снапшотов

vSAN Data Protection поддерживает до 200 снапшотов на ВМ, преодолевая ограничение в 32 снапшота при использовании традиционных методов в vCenter Server и API на основе VADP.

Динамическая группировка

Основой использования vSAN Data Protection являются «группы защиты» (protection groups). Это логические контейнеры, в которых можно группировать несколько ВМ для легкого и повторяемого создания и управления снапшотами. В пределах группы защиты можно определить политику, например, частоту защиты и расписание хранения. ВМ могут быть назначены статически или динамически с использованием символов подстановки «*» и «?». Например, назначение членства с помощью «SQL-*» позволяет защитить все ВМ с именем, включающим «SQL-».

Опциональная неизменяемость данных

Снапшоты могут быть сделаны неизменяемыми, что означает, что снапшот нельзя изменить или удалить. Эта опция, доступная в настройках группы защиты, обеспечивает базовую защиту от злонамеренных действий и интегрируется с VMware Live Cyber Recovery (VLCR), комплексным решением для защиты от вымогателей.

Защита системы

Снимки могут увеличивать потребление емкости, если скорость изменения данных и частота создания снапшотов высоки. Для защиты от непреднамеренных проблем с потреблением данных vSAN Data Protection приостанавливает создание снапшотов, если достигнуто 70% емкости кластера. Также автоматически истекают снапшоты пытающиеся превысить лимит в 200 снимков на ВМ.

Практическое использование vSAN Data Protection

Хотя технология впечатляет, важен результат. Легкая защита должна сочетаться с легким оперативным восстановлением для использования в реальных сценариях. Вот несколько примеров использования vSAN Data Protection:

1. Возврат существующих ВМ к предыдущему состоянию. Быстрое восстановление ВМ, которые могли быть случайно неправильно настроены, неудачно обновлены или подверглись подозрительной деятельности.
2. Восстановление удаленных ВМ. Легко восстановите ВМ, которые больше не зарегистрированы в vCenter Server, что помогает защититься от случайного или злонамеренного удаления ВМ.
3. Клонирование ВМ. Быстрое создание клона ВМ из снимка, что может быть простым и эффективным способом иметь несколько копий данных.
4. Защита от вымогателей. vSAN Data Protection можно использовать с VMware Live Cyber Recovery (VLCR), чтобы легко создать комплексное решение для защиты и восстановления от вымогателей.

На данный момент vSAN Data Protection ограничивается предоставлением локальной защиты ВМ. Но это может быть идеальным дополнением к существующим и более комплексным стратегиям резервного копирования 3-2-1. Для получения дополнительной информации и ответов на часто задаваемые вопросы, ознакомьтесь с vSAN Data Protection FAQs.

Заключение

vSAN Data Protection представляет собой лучший способ защиты и восстановления виртуальных машин. Она использует возможности vSAN ESA, чтобы предоставить преимущества, которые трудно достичь с внешними подходами на основе массивов. И, что самое главное, vSAN Data Protection уже доступна в вашей лицензии VCF.

После неудачного развертывания VCF 5.0 у автора блога vronin.nl остался vSAN Datastore на первом хосте в кластере, что блокировало повторную попытку развертывания.

В этом состоянии vSAN Datastore не может быть удален. Если попытаться его удалить через ESXi Host Client, опция будет неактивна:

Чтобы удалить хранилище данных vSAN и разделы дисков, сначала нужно подключиться по SSH к хосту и получить Sub-Cluster Master UUID кластера:

Далее копируем этот Sub-Cluster Master UUID в следующую команду:

esxcli vsan cluster leave -u <Sub-Cluster Master UUID>

В ESXi Host Client будет показываться, что датастора больше нет:

Для двойной проверки выполняем следующие команды в консоли ESXi:

esxcli vsan cluster list

esxcli vsan storage list

По результатам вывода команд, на хосте не настроены кластеры или хранилища vSAN. После этого повторная попытка развертывания кластера управления VCF будет успешной.

В конце прошлого года компания VMware выпустила версию решения VMware Cloud Director 10.5.1, предназначенного для управления программно-определяемым датацентром сервис-провайдеров. Это был небольшой сервисный релиз продукта, а вот в vCD 10.6 появилось уже довольно много всего нового.

VMware Cloud Director 10.6 теперь доступен в составе предложения VCF (VMware Cloud Foundation), начиная с 27 июня 2024 года.

В этом последнем обновлении вы найдете значительные улучшения и новые функции в следующих областях:

Основная платформа

Трехуровневая аренда

VMware Cloud Director позволяет облачным провайдерам создавать многоуровневую организационную структуру через интерфейс пользователя, известную как модель трехуровневой аренды, для создания субпровайдерских организаций с ограниченными административными привилегиями над определенным набором арендаторов.

С этой возможностью облачные провайдеры могут предоставлять ограниченный доступ к конкретным ресурсам и услугам внутри своей инфраструктуры, при этом гарантируя, что каждый арендатор имеет контролируемый доступ только к нужным ресурсам. Эта усовершенствованная модель аренды также обеспечивает большую масштабируемость, гибкость и безопасность, так как облачные провайдеры могут легко управлять и выделять ресурсы на различных уровнях администрирования.

Этот инновационный подход позволяет облачным провайдерам принимать различные бизнес-модели, такие как:

• Создание субпровайдерских организаций, что способствует вложенной многоуровневой аренде внутри крупных корпоративных организаций, позволяя создавать отдельные административные иерархии для разных отделов или дочерних компаний.
• Перепродажа облачных услуг через партнеров или MSP (managed service providers).

Этот выпуск приносит возможность трехуровневой аренды во все аспекты ресурсов и услуг, доступных через VMware Cloud Director, делая его идеальным решением для облачных провайдеров, стремящихся предлагать гибкие и масштабируемые облачные услуги своим клиентам.

Увеличенные лимиты

Этот выпуск значительно увеличивает максимальные параметры в нескольких областях платформы, таких как:

• Максимальное количество виртуальных машин на инстанс VMware Cloud Director увеличено до 55 000, независимо от состояния питания.
• Количество одновременно поддерживаемых удаленных консолей увеличено до 22 000.
• Максимальное количество пользователей, поддерживаемых платформой, увеличено до 300 000.
• Организационная модель для группы виртуальных датацентров (Org VDC) была переработана в трехуровневую структуру. В рамках этого нового дизайна субпровайдер теперь может управлять группами датацентров, которые могут вмещать до 2000 участников (ранее 16) и делиться сетями и каналами связи между ними.

Множественные снапшоты ВМ и vApp

VMware Cloud Director теперь предлагает улучшенную гибкость для виртуальных машин и vApps с возможностью делать множественные снимки ВМ или vApp, до максимального количества, установленного вашим облачным провайдером.

Content Hub

Администраторы кластеров Kubernetes теперь могут определять точные контрольные точки доступа, предоставляя индивидуальным пользователям или группам персонализированные разрешения на доступ к конкретным кластерам, пространствам имен или приложениям. Эта функция позволяет создать multi-tenant архитектуру, позволяющую нескольким организациям безопасно сосуществовать в одном Kubernetes окружении, каждая с изолированным пространством имен для развертывания, управления и контроля своих контейнеризованных рабочих нагрузок.

Также была выпущена новая версия Content Hub Operator, которая работает нативно в кластере Kubernetes и использует протокол WebSocket для высокопроизводительной связи с VMware Cloud Director. Оператор также предоставляет отчеты о совместимости в реальном времени на портал арендатора, позволяя владельцам кластеров принимать информированные решения о времени обновления для обеспечения бесшовной интеграции с VMware Cloud Director.

Распределенный глобальный каталог

Он позволяет создать глобальную мультисайтовую облачную архитектуру, обеспечивая бесшовный доступ к каталогам через несколько сайтов VMware Cloud Director (VCD), предоставляя единый каталог для арендаторов, независимо от инстанса vCenter или инфраструктуры SDDC. Вы можете использовать независимые от поставщика решения для совместного хранения данных (такие как NetApp, Dell, vSAN и т.д.), чтобы реплицировать данные и обеспечить глобальную согласованность каталога.

Множественные протоколы IDP и локальные пользователи

VMware Cloud Director позволяет организациям использовать несколько протоколов поставщиков индентификации (IDP), включая LDAP, SAML и OpenId Connect (OIDC), для более комплексного подхода к аутентификации. Используя внешних поставщиков, вы можете воспользоваться последними достижениями в технологиях аутентификации. Стоит отметить, что локальные пользователи по-прежнему поддерживаются в текущем выпуске, их использование в производственной среде прекращается, но они будут полностью поддерживаться до следующего крупного выпуска VMware Cloud Director.

Улучшенная производительность развертывания шаблонов ВМ

При развертывании шаблона ВМ на другом vCenter, используя VMware Cloud Director, система использует двухфазный подход для обеспечения эффективного развертывания. Изначально она пытается ускорить процесс путем клонирования шаблона ВМ напрямую, используя скорость и эффективность этого метода. Этот подход позволяет системе быстро создать новый инстанс ВМ без издержек на экспорт и импорт ВМ как OVF-файл. Однако, если операция клонирования сталкивается с любыми проблемами или ошибками, система автоматически переключается на более традиционный метод, используя экспорт/импорт OVF для развертывания ВМ. Этот резервный подход обеспечивает успешное завершение процесса развертывания, даже в случаях, когда клонирование может быть невозможным.

Улучшенное управление шифрованием

VMware Cloud Director 10.6 вводит несколько улучшений в функции управления шифрованием:

• Одновременная регистрация нескольких поставщиков ключей, обеспечивающая большую гибкость и масштабируемость.
• Имя кластера можно редактировать во время публикации поставщика ключей, что позволяет сервис-провайдерам легко идентифицировать, какой поставщик ключей принадлежит какому арендатору.
• При аутентификации поставщика ключей или регистрации нового ключа пользователи теперь могут выбрать генерацию нового ключа для каждой операции шифрования, обеспечивая дополнительную безопасность.
• Введена новая функция ротации ключей, позволяющая автоматическую ротацию ключей на основе настроек конфигурации. Этот процесс ненавязчив и обеспечивает бесшовное шифрование.
• VMware Cloud Director 10.6 вводит новую функцию, позволяющую пользователям применять различные политики шифрования к различным политикам хранения, предоставляя большую гибкость и настройку в их стратегиях шифрования.
• При удалении политики шифрования VMware Cloud Director 10.6 теперь предоставляет возможность "не перешифровывать" ранее зашифрованные данные.

Поддержка vSAN 4.1 NFS

VMware Cloud Director 10.6 теперь включает поддержку vSAN 4.1 NFS, обеспечивая безопасное совместное использование файлов с аутентификацией Kerberos. Эта интеграция позволяет использовать vSAN 4.1 как надежное и безопасное хранилище, предоставляя дополнительную возможность для совместного использования файлов в вашей организации.

Устранение уязвимости CVE-2024-22272

Для получения дополнительной информации об этой уязвимости и ее влиянии на продукты VMware, см. VMSA-2024-0014.

Сеть

Поддержка IPv6 для узлов VMware Cloud Director

VMware Cloud Director поддерживает развертывание ячеек устройств в IPv6 сетях, позволяя клиентам воспользоваться преимуществами современного сетевого протокола, сохраняя совместимость с существующей инфраструктурой.

Индивидуальный монитор здоровья

В рамках постоянных усилий по улучшению пользовательского опыта, VMware добавила Custom Health Monitors в дополнение к существующим HTTP-политикам. С этой функцией арендаторы теперь могут отслеживать и устранять неполадки различных характеристик здоровья своих балансируемых услуг, включая такие метрики, как время ответа, потеря пакетов и ошибки подключения. Это позволяет им принимать проактивные меры для поддержания надежности и отзывчивости услуг.

Логирование балансировщика нагрузки Avi

С новой функцией логирования Avi LB на уровне арендатора, арендаторы и облачные провайдеры теперь могут получить более глубокое понимание использования Avi LB. Эта функция предоставляет детализированное представление о действиях Avi LB, позволяя отслеживать модели использования, устранять события и экспортировать логи для аудита, соответствия и регуляторных целей.

WAF для Avi LB

Интеграция WAF (Web Application Firewall) с Avi LB и Cloud Director открывает новые возможности для клиентов по предоставлению дополнительных услуг своим конечным пользователям. Включение функций безопасности WAF в их портфель услуг позволяет обеспечить улучшенную защиту от веб-атак, повысить удовлетворенность клиентов и укрепить свои позиции на рынке.

С введением WAF появляются следующие преимущества:

• Улучшенная безопасность: WAF помогает защищаться от веб-атак, таких как SQL-инъекции и межсайтовый скриптинг (XSS), фильтруя входящий трафик и блокируя вредоносные запросы.
• Усиленное соответствие: WAF может помочь организациям соответствовать нормативным требованиям, предоставляя видимость веб-трафика и возможность блокировать определенные типы трафика или запросов.
• Увеличение доверия клиентов: предлагая WAF как дополнительную услугу, организации могут продемонстрировать свою приверженность безопасности и укрепить доверие своих клиентов.
• Конкурентное преимущество: WAF может стать ключевым отличием для организаций, стремящихся выделиться на переполненном рынке, так как обеспечивает дополнительный уровень безопасности и защиты.

Управление IP-адресами

Значительные обновления были внесены в управление IP-адресами, с упором на упрощение резервирования IP для рабочих нагрузок и выделения IP-адресов для долгоживущих услуг, таких как виртуальные IP-адреса балансировщиков нагрузки. Эти улучшения призваны соответствовать трехуровневой структуре разрешений, обеспечивая удобный опыт управления жизненным циклом IP-адресов, который исходит из IP-пулов для арендаторов, субпровайдеров и провайдеров.

IPsec VPN на шлюзах провайдеров и пограничных шлюзах

VMware Cloud Director расширил свои возможности IPsec VPN, включив установление туннеля на выделенных шлюзах провайдеров. Обновленная структура управления VPN теперь организована в трехуровневую модель, позволяя арендаторам, субпровайдерам и провайдерам настраивать и управлять VPN. С этой улучшенной возможностью провайдеры могут использовать Border Gateway Protocol (BGP) для контроля, какие IP-префиксы используют VPN. Более того, провайдеры и субпровайдеры могут автоматизировать настройку BGP для своих арендаторов, используя IP-пространства для управления сетевыми назначениями для публичного и частного адресации. Более того, провайдеры и субпровайдеры могут делегировать определенные конфигурации BGP своим арендаторам, предоставляя большую гибкость и контроль.

Новый UX для развертывания контроллеров Avi и NSX Cloud Connectors

VMware Cloud Director 10.6 вводит значительные улучшения в развертывание контроллеров Avi и NSX Cloud Connectors, тем самым увеличивая масштабируемость Avi LB. Новый пользовательский опыт позволяет администраторам легко добавлять больше облачных контроллеров к существующим контроллерам Avi, что увеличивает емкость и производительность. Кроме того, UX предоставляет ценные данные о потреблении ресурсов для контроллеров Avi, облаков NSX и пограничных шлюзов, что позволяет администраторам принимать информированные решения о выделении и оптимизации ресурсов.

Интеграция логов безопасности

VMware Cloud Director реализует прием и обработку логов, бесшовно подключаясь к VMware Aria Operations for Logs. Логи NSX Gateway Firewall и Distributed Firewall теперь автоматически обрабатываются VMware Aria Operations for Logs, предоставляя легкий доступ к этим логам через портал арендатора. Эта интеграция позволяет арендаторам быстро находить конкретные события, используя фильтры и временные диапазоны, и экспортировать логи в CSV-файлы для дальнейшего анализа и отчетности.

Object Storage Extension 3.1

В версии расширения VMware Cloud Director Object Storage Extension 3.1 появились следующие новые функции:

• Поддержка MinIO для внешних кластеров Kubernetes.
• Пересылка клиентских IP для настройки доступа к бакетам.
• Улучшенный интерфейс резервного копирования и восстановления Kubernetes для лучшей видимости и управления.
• Обновления OSIS (Object Storage Interoperability Service) для совместимых с S3 поставщиков хранилищ и асинхронного включения арендаторов.

Загрузите OSE 3.1 отсюда и прочитайте документацию по OSE 3.1 здесь.

Несколько полезных ресурсов о VMware Cloud Director 10.6

• Начните с VMware Cloud Director 10.6, загрузив последнюю версию отсюда.
• Для получения подробной информации о том, как использовать и настраивать VCD 10.6, ознакомьтесь с официальной документацией здесь.
• Для получения дополнительных ресурсов и информации о VCD посетите специальную страницу VMware Cloud Director на сайте vmware.com здесь.
• Для просмотра руководства по API прочитайте старое руководство по API здесь и руководство по OpenAPI здесь.

Недавно мы писали о новых возможностях обновленной версии платформы VMware vSphere 8.0 Update 3, а также о том, что нового появилось в плане основных функций хранилищ (Core Storage). Сегодня мы расскажем о новой версии решения VMware vSphere IaaS Control Plane 8.0.

Для начала - что это за решение? VMware внедрила декларативный API в vSphere, чтобы обеспечить современный опыт IaaS для потребителей облачных услуг. Решение vSphere IaaS Control Plane основывается на работе, проделанной в рамках инициативы vSphere with Tanzu, и расширяет её новым набором возможностей IaaS.

Давайте посмотрим, что нового появилось с выпуском vSphere 8 Update 3.

Независимая служба TKG Service

VMware представляет независимую службу TKG Service, которая отделена от vCenter и реализована как основная служба Supervisor Service. Это позволит выпускать асинхронные обновления сервиса и предоставлять новые версии Kubernetes быстрее, чем когда-либо.

Администраторы смогут обновлять TKG Service без необходимости обновлять Supervisor или vCenter, чтобы без проблем получать и использовать новые версии Kubernetes. Эти версии затем могут быть использованы непосредственно потребителями услуг.

Local Consumption Interface (LCI)

Интерфейс потребления облака (Cloud Consumption Interface, CCI) в Aria Automation предоставляет пользовательский интерфейс для создания виртуальных машин, кластеров TKG, балансировщиков нагрузки и запросов постоянных томов (Persistent Volume Claims).

Этот интерфейс теперь доступен в vCenter для каждого отдельного пространства имен. Пользовательский интерфейс поддерживает сложные спецификации для виртуальных машин и кластеров TKG, автоматически генерируя YAML для пользователей, которые хотят взаимодействовать с API напрямую. Интерфейс виртуальной машины поддерживает создание секретов и configmap для хранения конфигурации облака для настройки экземпляра виртуальной машины. Мастер создания кластеров расширен для поддержки сложных типов кластеров, которые могут включать смешанные рабочие узлы с конфигурациями GPU и без GPU.

Автомасштабирование для кластеров Kubernetes

VMware представила автоматическое масштабирование для кластеров Kubernetes с использованием Cluster Autoscaler. Это позволит кластерам Kubernetes соответствовать текущим потребностям, уменьшать количество узлов при низкой загрузке и увеличивать их количество при росте запросов. Рабочие узлы будут автоматически добавляться, когда ресурсов недостаточно для выполнения планирования подов.

Cluster Autoscaler может быть установлен как стандартный пакет с использованием kubectl или tanzu cli. Версия пакета должна соответствовать минорным версиям Kubernetes, например, чтобы установить пакет на кластер Kubernetes версии v1.26.5, необходимо установить пакет Cluster Autoscaler версии v1.26.2.

Минимально требуемая версия для Cluster Autoscaler — v1.25.

Поддержка растянутых кластеров vSAN Stretched Cluster

Одной из самых востребованных опций конфигурации была возможность развертывания Supervisor на растянутом кластере vSAN, охватывающем два физических местоположения или сайта. В этом релизе VMware учла основные требования для поддержки этой реализации, однако есть некоторые моменты, которые следует учитывать.

Основное внимание следует уделить доступности etcd, который является основной базой данных, хранящей все данные кластера Kubernetes. Etcd использует механизм кворума, что означает, что для его работы необходимо, чтобы более половины реплик были доступны в любое время. Поэтому нет смысла распределять нечетное количество виртуальных машин с Control Pane (CP) по двум сайтам. Вместо этого, для развертывания Active/Active, VMware рекомендует:

• Три виртуальные машины CP Supervisor (SV CP) должны быть размещены на одном сайте, при этом этот сайт может быть любым из двух, поскольку оба сайта активны.
• Все виртуальные машины CP любого кластера TKG должны быть размещены на одном сайте, который может быть любым из двух.

Чтобы контролировать размещение, администратору необходимо настроить правила Affinity rules VM-host для каждого набора связанных виртуальных машин, чтобы привязать виртуальную машину к определенному сайту.

Администраторы также должны создать политику растянутого кластера vSAN с определенными настройками, такими как толерантность к сбоям сайта, установленная на двойное зеркалирование сайта, и включенное принудительное предоставление ресурсов. Поскольку политика растянутого кластера vSAN является требованием для библиотек контента и самого Supervisor, сначала необходимо включить растянутый кластер vSAN, а затем уже Supervisor.

Из-за сложности этой архитектуры VMware настоятельно рекомендует следовать документации по передовым методикам, которая есть для этого случая.

Автоматическая ротация сертификатов Supervisor

Еще одна новая функция, которую VMware добавила в этом выпуске, — автоматическая ротация сертификатов Supervisor. По умолчанию сертификаты Supervisor действительны в течение года после первоначального развертывания. Ранее клиенты могли заменять сертификаты, выполняя ряд ручных шагов. Чтобы упростить этот процесс, его автоматизировали, и сертификаты будут просто заменяться по мере приближения их срока истечения без вмешательства пользователя.

Аларм сработает только в случае, если процесс автоматического обновления не удастся, и это будет видно в интерфейсе vCenter. По умолчанию процесс попытается обновить сертификат снова через 12 часов. Как только замена будет успешной, алерт исчезнет.

Пользователи также могут решить заменить сертификат вручную.

Расширенная конфигурация класса виртуальных машин (VM Class Expanded Configuration)

Пользовательский интерфейс класса виртуальных машин (VM Class) в vCenter был обновлен для поддержки значительно расширенного набора опций конфигурации оборудования. Перемещение конфигурации оборудования в класс виртуальных машин (VM Class) упрощает файл спецификации виртуальной машины, позволяя пользователям ссылаться на один класс виртуальной машины как на шаблон для полной спецификации, а не настраивать отдельные параметры напрямую.

Теперь администраторы имеют детальный контроль над конфигурацией оборудования, доступной для пользователей среды самообслуживания. Конфигурация оборудования более точно соответствует моделям потребления в публичных облаках.

Резервное копирование и восстановление кластера

Velero теперь является основным сервисом, включенным в Supervisor. Этот сервис координирует резервное копирование и восстановление как кластера Supervisor, так и любых развернутых кластеров TKG. Velero необходимо устанавливать на отдельные кластеры TKG через CLI. Резервное копирование и восстановление также выполняются через CLI. Резервное копирование и восстановление Supervisor осуществляется через интерфейс vCenter.

Сервис виртуальных машин (VM Service) – резервное копирование и восстановление виртуальных машин

Служба VM Service теперь включает возможность резервного копирования и восстановления виртуальных машин с использованием любого программного обеспечения VMware Advanced Data Protection. Этот метод не требует изменений в вашем инструменте резервного копирования или специальной конфигурации. Резервное копирование можно выполнять на уровне виртуальных машин или для всего пространства имен. Для пространства имен вы просто указываете пул ресурсов, который поддерживает пространство имен в vCenter.

Когда виртуальная машина развертывается с использованием VM Service, в Supervisor создаются объекты пользовательских ресурсов, которые определяют состояние виртуальных машин, а также поддерживающих объектов, которые облегчают начальную настройку виртуальной машины. Эти метаданные должны быть восстановлены как часть процесса резервного копирования/восстановления.

Виртуальные машины, развернутые с использованием VM Service, теперь сохраняют в полях Extra-Config всю информацию, необходимую для воссоздания метаданных Supervisor. Этот процесс регистрации автоматический и происходит при восстановлении. Если автоматическая регистрация по какой-либо причине не удается, например, из-за отсутствия политики хранения или класса виртуальных машин, доступен API для ручного запуска регистрации после устранения проблемы.

Вчера мы писали о новых возможностях последнего пакета обновлений VMware vSphere 8.0 Update 3, а сегодня расскажем что нового появилось в плане основных функций хранилищ (Core Storage).

Каждое обновление vSphere 8 добавляет множество возможностей для повышения масштабируемости, устойчивости и производительности. В vSphere 8 Update 3 продолжили улучшать и дорабатывать технологию vVols, добавляя новые функции.

Продолжая основной инженерный фокус на vVols и NVMe-oF, VMware также обеспечивает их поддержку в VMware Cloud Foundation. Некоторые функции включают дополнительную поддержку кластеризации MS WSFC на vVols и NVMe-oF, улучшения по возврату свободного пространства (Space Reclamation), а также оптимизации для VMFS и NFS.

Ключевые улучшения

• Поддержка растянутых кластеров хранилищ (Stretched Clusters) для vVols
• Новая спецификация vVols VASA 6
• Кластеризация VMDK для NVMe/TCP
• Ограничение максимального количества хостов, выполняющих Unmap
• Поддержка NFS 4.1 Port Binding и nConnect
• Дополнительная поддержка CNS/CSI для vSAN

vVols

Поддержка растянутого кластера хранилища vVols на SCSI

Растянутый кластер хранения vVols (vVols-SSC) был одной из самых запрашиваемых функций для vVols в течение многих лет, особенно в Европе. В vSphere 8 U3 добавлена поддержка растянутого хранилища vVols только на SCSI (FC или iSCSI). Первоначально Pure Storage, который был партнером по дизайну этой функции, будет поддерживать vVols-SSC, но многие из партнеров VMware по хранению также активно работают над добавлением данной поддержки.

Почему это заняло так много времени?

Одна из причин, почему реализация vVols-SSC заняла столько времени, заключается в дополнительных улучшениях, необходимых для защиты компонентов виртуальных машин (VMCP). Когда используется растянутое хранилище, необходимо наличие процесса для обработки событий хранения, таких как Permanent Device Loss (PDL) или All Paths Down (APD). VMCP — это функция высокой доступности (HA) vSphere, которая обнаруживает сбои хранения виртуальных машин и обеспечивает автоматическое восстановление затронутых виртуальных машин.

Сценарии отказа и восстановления

• Контейнер/datastore vVols становится недоступным. Контейнер/datastore vVols становится недоступным, если либо все пути данных (к PE), либо все пути управления (доступ к VP, предоставляющим этот контейнер) становятся недоступными, либо если все пути VASA Provider, сообщающие о растянутом контейнере, отмечают его как UNAVAILABLE (новое состояние, которое VP может сообщить для растянутых контейнеров).
• PE контейнера vVols может стать недоступным. Если PE для контейнера переходит в состояние PDL, то контейнер также переходит в состояние PDL. В этот момент VMCP будет отвечать за остановку виртуальных машин на затронутых хостах и их перезапуск на других хостах, где контейнер доступен.
• Контейнер или PE vVols становится доступным снова или восстанавливается подключение к VP. Контейнер вернется в доступное состояние из состояния APD, как только хотя бы один VP и один PE станут доступны снова. Контейнер вернется в доступное состояние из состояния PDL только после того, как все виртуальные машины, использующие контейнеры, будут выключены, и все клиенты, имеющие открытые файловые дескрипторы к хранилищу данных vVols, закроют их.

Поведение растянутого контейнера/хранилища данных довольно похоже на VMFS, и выход из состояния PDL требует уничтожения PE, что может произойти только после освобождения всех vVols, связанных с PE. Точно так же, как VMFS (или устройство PSA) не может выйти из состояния PDL, пока все клиенты тома VMFS (или устройства PSA) не закроют свои дескрипторы.

Требования

• Хранилище SCSI (FC или iSCSI)
• Макс. время отклика между хостами vSphere — 11 мс
• Макс. время отклика массива хранения — 11 мс
• Выделенная пропускная способность сети vSphere vMotion — 250 Мбит/с
• Один vCenter (vCenter HA не поддерживается с vVols)
• Контроль ввода-вывода хранения не поддерживается на datastore с включенным vVol-SSC

Дополнительная поддержка UNMAP

Начиная с vSphere 8.0 U1, config-vvol теперь создается с 255 ГБ VMFS vVol вместо 4 ГБ. Это добавило необходимость в возврате свободного пространства в config-vvol. В 8.0 U3 VMware добавила поддержку как ручного (CLI), так и автоматического UNMAP для config-vvol для SCSI и NVMe.

Это гарантирует, что при записи и удалении данных в config-vvol обеспечивается оптимизация пространства для новых записей. Начиная с vSphere 8.0 U3, также поддерживается команда Unmap для хранилищ данных NVMe-oF, а поддержка UNMAP для томов SCSI была добавлена в предыдущем релизе.

Возврат пространства в хранилищах виртуальных томов vSphere описан тут.

Кликните на картинку, чтобы посмотреть анимацию:

Поддержка кластеризации приложений на NVMe-oF vVols

В vSphere 8.0 U3 VMware расширила поддержку общих дисков MS WSFC до NVMe/TCP и NVMe/FC на основе vVols. Также добавили поддержку виртуального NVMe (vNVME) контроллера для гостевых кластерных решений, таких как MS WSFC.

Эти функции были ограничены SCSI на vVols для MS WSFC, но Oracle RAC multi-writer поддерживал как SCSI, так и NVMe-oF. В vSphere 8.0 U3 расширили поддержку общих дисков MS WSFC до vVols на базе NVMe/TCP и NVMe/FC. Также была добавлена поддержка виртуального NVMe (vNVME) контроллера виртуальной машины в качестве фронтенда для кластерных решений, таких как MS WSFC. Обратите внимание, что контроллер vNVMe в качестве фронтенда для MS WSFC в настоящее время поддерживается только с NVMe в качестве бэкенда.

Обновление отчетности по аутентификации хостов для VASA Provider

Иногда при настройке Storage Provider для vVols некоторые хосты могут не пройти аутентификацию, и это может быть сложно диагностировать. В версии 8.0 U3 VMware добавила возможность для vCenter уведомлять пользователей о сбоях аутентификации конкретных хостов с VASA провайдером и предоставили механизм для повторной аутентификации хостов в интерфейсе vCenter. Это упрощает обнаружение и решение проблем аутентификации Storage Provider.

Гранулярность хостов Storage Provider для vVols

С выходом vSphere 8 U3 была добавлена дополнительная информация о хостах для Storage Provider vVols и сертификатах. Это предоставляет клиентам и службе поддержки дополнительные детали о vVols при устранении неполадок.

NVMe-oF

Поддержка NVMe резервирования для кластерного VMDK с NVMe/TCP

В vSphere 8.0 U3 была расширена поддержка гостевой кластеризации до NVMe/TCP (первоначально поддерживалась только NVMe/FC). Это предоставляет клиентам больше возможностей при использовании NVMe-oF и желании перенести приложения для гостевой кластеризации, такие как MS WSFC и Oracle RAC, на хранилища данных NVMe-oF.

Поддержка NVMe Cross Namespace Copy

В предыдущих версиях функция VAAI, аппаратно ускоренное копирование (XCOPY), поддерживалась для SCSI, но не для NVMe-oF. Это означало, что копирование между пространствами имен NVMe использовало ресурсы хоста для передачи данных. С выпуском vSphere 8.0 U3 теперь доступна функция Cross Namespace Copy для NVMe-oF для поддерживаемых массивов. Применение здесь такое же, как и для SCSI XCOPY между логическими единицами/пространствами имен. Передачи данных, такие как копирование/клонирование дисков или виртуальных машин, теперь могут работать значительно быстрее. Эта возможность переносит функции передачи данных на массив, что, в свою очередь, снижает нагрузку на хост.

Кликните на картинку, чтобы посмотреть анимацию:

VMFS

Сокращение времени на расширение EZT дисков на VMFS

В vSphere 8.0 U3 был реализован новый API для VMFS, чтобы ускорить расширение блоков на диске VMFS, пока диск используется. Этот API может работать до 10 раз быстрее, чем существующие методы, при использовании горячего расширения диска EZT на VMFS.

Виртуальные диски на VMFS имеют тип аллокации, который определяет, как резервируется основное хранилище: Thin (тонкое), Lazy Zeroed Thick (толстое с занулением по мере обращения) или Eager Zeroed Thick (толстое с предварительным занулением). EZT обычно выбирается на VMFS для повышения производительности во время выполнения, поскольку все блоки полностью выделяются и зануляются при создании диска. Если пользователь ранее выбрал тонкое выделение диска и хотел преобразовать его в EZT, этот процесс был медленным. Новый API позволяет значительно это ускорить.

Кликните на картинку для просмотра анимации:

Ограничение количества хостов vSphere, отправляющих UNMAP на VMFS datastore

В vSphere 8.0 U2 VMware добавила возможность ограничить скорость UNMAP до 10 МБ/с с 25 МБ/с. Это предназначено для клиентов с высоким уровнем изменений или массовыми отключениями питания, чтобы помочь уменьшить влияние возврата пространства на массив.

Кликните на картинку для просмотра анимации:

По умолчанию все хосты в кластере, до 128 хостов, могут отправлять UNMAP. В версии 8.0 U3 добавлен новый параметр для расширенного возврата пространства, называемый Reclaim Max Hosts. Этот параметр может быть установлен в значение от 1 до 128 и является настройкой для каждого хранилища данных. Чтобы изменить эту настройку, используйте ESXCLI. Алгоритм работает таким образом, что после установки нового значения количество хостов, отправляющих UNMAP одновременно, ограничивается этим числом. Например, если установить максимальное значение 10, в кластере из 50 хостов только 10 будут отправлять UNMAP на хранилище данных одновременно. Если другие хосты нуждаются в возврате пространства, то, как только один из 10 завершит операцию, слот освободится для следующего хоста.

См. статью Space Reclamation on vSphere VMFS Datastores.

Пример использования : esxcli storage vmfs reclaim config set -l <Datastore> -n <number_of_hosts>

Вот пример изменения максимального числа хостов, отправляющих UNMAP одновременно:

PSA

Поддержка уведомлений о производительности Fabric (FPIN, ошибки связи, перегрузка)

VMware добавила поддержку Fabric Performance Impact Notification (FPIN) в vSphere 8.0 U3. С помощью FPIN слой инфраструктуры vSphere теперь может обрабатывать уведомления от SAN-коммутаторов или целевых хранилищ о падении производительности каналов SAN, чтобы использовать исправные пути к устройствам хранения. Он может уведомлять хосты о перегрузке каналов и ошибках. FPIN — это отраслевой стандарт, который предоставляет средства для уведомления устройств о проблемах с соединением.

Вы можете использовать команду esxcli storage FPIN info set -e= <true/false>, чтобы активировать или деактивировать уведомления FPIN.

Кликните на картинку, чтобы посмотреть анимацию:

NFS

Привязка порта NFS v4.1 к vmk

Эта функция добавляет возможность байндинга соединения NFS v4.1 к определенному vmknic для обеспечения изоляции пути. При использовании многопутевой конфигурации можно задать несколько vmknic. Это обеспечивает изоляцию пути и помогает повысить безопасность, направляя трафик NFS через указанную подсеть/VLAN и гарантируя, что трафик NFS не использует сеть управления или другие vmknic. Поддержка NFS v3 была добавлена еще в vSphere 8.0 U1. В настоящее время эта функция поддерживается только с использованием интерфейса esxcli и может использоваться совместно с nConnect.

См. статью "Настройка привязки VMkernel для хранилища данных NFS 4.1 на хосте ESXi".

Поддержка nConnect для NFS v4.1

Начиная с версии 8.0 U3, добавлена поддержка nConnect для хранилищ данных NFS v4.1. nConnect предоставляет несколько соединений, используя один IP-адрес в сессии, таким образом расширяя функциональность агрегации сессий для этого IP. С этой функцией многопутевая конфигурация и nConnect могут сосуществовать. Клиенты могут настроить хранилища данных с несколькими IP-адресами для одного сервера, а также с несколькими соединениями с одним IP-адресом. В настоящее время максимальное количество соединений ограничено 8, значение по умолчанию — 1. Текущие версии реализаций vSphere NFSv4.1 создают одно соединение TCP/IP от каждого хоста к каждому хранилищу данных. Возможность добавления нескольких соединений на IP может значительно увеличить производительность.

При добавлении нового хранилища данных NFSv4.1, количество соединений можно указать во время монтирования, используя команду:

esxcli storage nfs41 add -H <host> -v <volume-label> -s <remote_share> -c <number_of_connections>

Максимальное количество соединений на сессию по умолчанию ограничено "4", однако его можно увеличить до "8" с помощью продвинутого параметра NFS:

esxcfg-advcfg -s 8 /NFS41/MaxNConnectConns
esxcfg-advcfg -g /NFS41/MaxNConnectConns

Общее количество соединений, используемых для всех смонтированных хранилищ данных NFSv4.1, ограничено 256.

Для существующего хранилища данных NFSv4.1, количество соединений можно увеличить или уменьшить во время выполнения, используя следующую команду:

esxcli storage nfs41 param set -v <volume-label> -c <number_of_connections>


Это не влияет на многопутевую конфигурацию. NFSv4.1 nConnect и многопутевые соединения могут сосуществовать. Количество соединений создается для каждого из многопутевых IP.

esxcli storage nfs41 add -H <IP1,IP2> -v <volume-label> -s <remote_share> -c <number_of_connections>

Кликните на картинку, чтобы посмотреть анимацию:

CNS/CSI

Поддержка 250 файловых томов для vSAN ESA

В настоящее время CNS поддерживает только 100 файловых томов. В vSphere 8.0 U3 этот лимит увеличен до 250 томов. Это поможет масштабированию для клиентов, которым требуется больше файловых хранилищ для постоянных томов (PVs) или постоянных запросов томов (PVCs) в Kubernetes (K8s).

Поддержка файловых томов в топологии HCI Mesh в одном vCenter

Добавлена поддержка файловых томов в топологии HCI Mesh в пределах одного vCenter.

Поддержка CNS на TKGs на растянутом кластере vSAN

Появилась поддержка растянутого кластера vSAN для TKGs для обеспечения высокой доступности.

Миграция PV между несвязанными datastore в одном VC

Возможность перемещать постоянный том (PV), как присоединённый, так и отсоединённый, с одного vSAN на другой vSAN, где нет общего хоста. Примером этого может быть перемещение рабочей нагрузки Kubernetes (K8s) из кластера vSAN OSA в кластер vSAN ESA.

Поддержка CNS на vSAN Max

Появилась поддержка развертывания CSI томов для vSAN Max при использовании vSphere Container Storage Plug-in.

VMware VMmark 4.0 - это бесплатный кластерный бенчмарк, который измеряет производительность и масштабируемость виртуальных корпоративных сред.

VMmark 4 продолжает использовать дизайн и архитектуру предыдущих версий VMmark, предоставляя улучшенную автоматизацию и отчетность. Он использует модульный дизайн нагрузки с разнородными приложениями, включающий обновленные версии нескольких нагрузок из VMmark 3, также в нем появились и новые современные приложения, которые более точно соответствуют современным корпоративным виртуальным средам.

VMmark 4 также включает инфраструктурные нагрузки, такие как vMotion, Storage vMotion, Cross vMotion и Clone & Deploy. В дополнение к ним, VMware vSphere DRS также работает в тестируемом кластере для балансировки нагрузок. В VMmark 4.0 было сделано улучшение полностью автоматизированного процесса развертывания, который появился в VMmark 3 - это сокращает время, необходимое пользователям для получения ценных результатов. Большинство пользователей теперь смогут перейти от загружаемого шаблона VMmark до результатов VMmark 4 примерно за два часа для "турбо" запуска.

Бенчмарк VMmark 4:

• Позволяет точно и повторяемо оценивать производительность виртуальных датацентров на основе vSphere.
• Использует разнообразные традиционные, устаревшие и современные нагрузки приложений в разнородном модульном подходе.
• Облегчает анализ и сравнение изменений в оборудовании, программном обеспечении и конфигурациях виртуальных сред VMware.
• Уровни создаваемой нагрузки теперь значительно выше, чем в предыдущих версиях VMmark, чтобы лучше отражать современные реалии.

Обновления удобства использования VMmark 4:

• Новый режим "Быстрый старт" для развертывания, запуска и получения результатов бенчмарка с помощью одной команды.
• Новые режимы развертывания, которые позволяют большую гибкость в распределении виртуальных машин по более разнообразным хранилищам.
• Функциональность частичных модулей (Partial Tile) для увеличения гранулярности бенчмарка через предписанное включение рабочих нагрузок приложений в конечный модуль.
• Дизайн "Автоматизация в первую очередь" - многие основные операции администрирования vSphere теперь доступны пользователям. Операции, такие как deleting_all_vmmark4, manual_xvmotion и power_vmmark4_tiles, помогают пользователям в полной автоматизации VMmark 4. Посмотрите вывод команды vmmark4service для получения списка из более чем 20 новых доступных операций.
• Улучшенная HTML-отчетность - пользователи теперь автоматически получают улучшенный HTML-вывод для пропускной способности, качества обслуживания и операций инфраструктуры для каждого запуска.
• Новое приложение "disclosure creator", которое упрощает и автоматизирует создание HTML файлов.
• Сбор данных о потреблении энергии - новый подход VMmark 4 к пониманию потребления энергопотребления. Этот режим собирает метрики энергопотребления на тестируемых системах и генерирует улучшенный HTML-отчет, чтобы помочь пользователям посчитать потребление энергии как хостами, так и виртуальными машинами.
• Интеграция оповещений - оповещения в Slack и Google Chat легко встраиваются в VMmark 4 и включаются одним параметром.

Рабочие нагрузки приложений VMmark 4:

• NoSQLBench - это новая рабочая нагрузка приложения в VMmark 4, используемая для анализа производительности новой распределенной NoSQL базы данных Apache Cassandra на 3 узлах.
• SocialNetwork - эта новая рабочая нагрузка приложения в VMmark использует Docker-контейнеры для моделирования социальной сети с операциями, такими как создание постов, подписка на пользователей и т.д.
• DVDstore (обновлено до версии 3.5) - включает PostgreSQL и параллельную загрузку базы данных, сокращая время на развертывание первого модуля.
• Weathervane (обновлено до версии 2.0) - это масштабируемое веб-приложение, имитирующее онлайн-аукцион, теперь работает в Kubernetes контейнерах и в виртуальных машинах.
• Standby - сервер Standby имитирует heartbeat-сервер, который периодически пингуется, чтобы убедиться, что он все еще работает и подключен.

Инфраструктурные нагрузки VMmark 4:

• vMotion - эта операция инфраструктуры выполняет живую миграцию одной из Standby ВМ по круговой схеме, чтобы смоделировать современные операции системного администратора.
• Storage vMotion - для этой операции одна из ВМ AuctionWebF мигрируется на указанное пользователем хранилище для обслуживания, а затем через некоторое время возвращается в исходное место.
• Cross vMotion (XvMotion) - эта операция одновременно перемещает одну из ВМ DS3WebA на альтернативный хост и хранилище для обслуживания. Аналогично операции Storage vMotion, через некоторое время ВМ возвращается в исходное место.
• Автоматическое балансирование нагрузки (DRS) - VMmark требует, чтобы DRS был включен и работал, чтобы гарантировать типичные операции ребалансировки в тестируемой среде.

Скачать VMware VMmark 4.0 можно по этой ссылке.

Также на днях стали доступны первые результаты тестирования производительности различного оборудования с помощью VMmark 4.0. Их можно посмотреть вот тут.

Некоторые пользователи, применяющие архитектуру VMware HCI Mesh для подключения емкостей удаленных кластеров в архитектуру VMware vSAN Express Storage Architecture (ESA) спрашивают - а можно ли таким образом подключить и емкости кластеров OSA (Original Storage Architecture)?

Напомним, что технология HCI Mesh появилась в VMware vSphere 7 Update 1, она позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов).

Мы уже касались этого вопроса здесь и указали на то, что это на данный момент не поддерживается. Дункан Эппинг вот тут рассказал о том, что это не только не сейчас поддерживается, но и невозможно.

Делов в том, что vSAN HCI Mesh (она же технология Datastore Sharing) использует проприетарный протокол vSAN, который называется Reliable Datagram Transport (RDT). При использовании vSAN OSA применяется другая версия протокола RDT, чем та, что используется в vSAN ESA, и в данный момент эти протоколы несовместимы. В итоге, нельзя использовать vSAN Datastore Sharing для предоставления емкости кластеров OSA в ESA или наоборот.

В будущем планируется исправить эту ситуацию, но в данный момент обходного пути нет.

Продолжаем рассказывать о возможностях решения VMware Cloud Director Object Storage Extension, которое предназначено для поддержки хранилищ S3 в инфраструктуре сервис-провайдеров, которые работают на базе VMware Cloud Director. О версии 2.1.1 этого продукта мы писали вот тут, а сегодня расскажем про версию Cloud Director Object Storage Extension 3.0, которая вышла недавно.

В этом выпуске VMware продолжает улучшать свои облачные инфраструктурные решения Cloud Director, предоставляя провайдерам больше гибкости, улучшенной доступности, масштабируемости и эффективности. Давайте подробно рассмотрим, что нового в этом релизе.

1. Установка VMware Cloud Director Add-on

Ключевым нововведением в версии 3.0 является упрощенный процесс установки VMware Cloud Director Object Storage Extension. Эта функция расширила доступность решения для провайдеров, поскольку администраторы теперь могут удобно устанавливать, обновлять и удалять расширения напрямую из пользовательского интерфейса аддонов VMware Cloud Director. Облачные провайдеры могут обеспечить более плавную работу с задачами в результате этого обновления.

Будучи установленным в качестве аддона решение работает как контейнерное приложение в среде Kubernetes. Облачные провайдеры могут развертывать расширение на мультиоблачный кластер Tanzu Kubernetes Grid или на кластер Kubernetes, соответствующий стандартам CNCF, за пределами VMware Cloud Director. Это улучшение предлагает гибкость и простую интеграцию с различными конфигурациями инфраструктуры, расширяя возможности развертывания для облачных провайдеров. Кроме того, интеграция с Tanzu Kubernetes Grid приносит дополнительные преимущества, например оптимизированную работу через стандартные пакеты, такие как Contour для балансировки нагрузки сервиса, Cert-manager для управления сертификатами TLS и метрики сервиса Grafana.

2. Конфигурация развертывания Day-2 через пользовательский интерфейс

Администраторы облачных провайдеров теперь имеют расширенное управление конфигурацией объектного хранилища напрямую из портала провайдера VMware Cloud Director. Задачи, такие как установка количества реплик, управление сертификатами TLS, подключение к базам данных, настройка платформ хранения и другие, могут быть запущены через пользовательский интерфейс. Эти улучшения пользовательского интерфейса упрощают процесс конфигурации, делая его более интуитивным и эффективным для администраторов.

3. Интеграция VMware Cloud Director с решениями для данных

Версия 3.0 представляет интуитивную интеграцию с экземплярами VMware Postgres из Solutions organization, что позволяет администраторам провайдера назначать их в качестве базы данных для Object Storage Extension. Эта интеграция упрощает задачи управления базами данных и повышает общую эффективность продукта.

4. Накатываемые обновления

С установкой дополнений, расширение объектного хранилища Cloud Director теперь поддерживает постепенные обновления, гарантируя, что изменения конфигурации автоматически проверяются и применяются. Администраторы облачных провайдеров могут легко масштабировать расширение вверх или вниз напрямую из портала провайдера Cloud Director, что является еще одной функцией, улучшающей операционную гибкость.

5. Улучшения для S3 и OSIS

Версия 3.0 принесла значительные улучшения в плане поддержки S3, включая возможность возврата ARN для арендаторов и улучшенный пользовательский опыт для защиты кластера Kubernetes. Кроме того, интерфейс Object Storage Interoperability Services (OSIS) был улучшен для адаптации к различным поставщикам хранилищ, что улучшило совместимость и взаимодействие.

6. Обновленная матрица поддержки

Версия 3.0 вводит обновленную матрицу поддержки, сертифицируя новые версии продуктов, включая VMware Cloud Director, VMware Cloud Director Container Service Extension и различные платформы хранения. Это обеспечивает совместимость и надежность для провайдеров, использующих облачные инфраструктурные решения VMware.

Ознакомьтесь с Release Notes и страницей документации, чтобы получить глубокое понимание новых функций, процесса обновления и ограничений. Вы можете обновиться напрямую до Cloud Director Object Storage Extension 3.0 с версий 2.X. Подробнее об этом рассказано тут.

Продолжаем рассказывать о производительности решения vSAN Express Storage Architecture (ESA), где реализовано высокопроизводительное кодирование RAID 5/6 с исправлением ошибок. Клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, которые также эффективны с точки зрения использования пространства, при этом соблюдается высокий уровень производительности. Все это достигается с использованием технологии RAID-6 на базе новой журналируемой файловой системы и формата объектов.

Компания VMware провела тестирование работы баз данных Oracle в среде vSAN ESA и опубликовала некоторые результаты.

Тестовый стенд

Тестовая площадка представляла собой кластер из 8 узлов vSAN 8 Express Storage Architecture (ESA) со следующими настройками:

• Версия vCenter 8.0.2 сборка 22385739
• 8 серверов Lenovo ThinkAgile VX7531 Node, 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU @ 2.60GHz, 1TB RAM
• VMware ESXi 8.0.2, сборка 22380479 с vSAN ESA (все хранилища - NVMe)
• Oracle 21.13 Grid Infrastructure, ASM Storage и Linux udev (размер блока базы данных 8k)
• OEL UEK 8.9

Детали кластера vSAN Express Storage Architecture (ESA) "env175" показаны ниже. Кластер ESA состоит из 8 серверов Lenovo ThinkAgile VX7531, как показано на картинке:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 2 сокета, 28 ядер на сокет, Intel Xeon Gold 6348 CPU на частоте 2.60GHz и 1TB RAM:

Каждый сервер Lenovo ThinkAgile VX7531 имеет 6 внутренних накопителей NVMe, таким образом каждый сервер дает 6 внутренних устройств NVMe в качестве емкости датастора vSAN ESA:

Информация о сервере ThinkAgile VX7531 "env175-node1.pse.lab" в части деталей HBA и внутренних устройств NVMe:

Политики хранения кластера vSAN Express Storage Architecture (ESA) показаны на картинке ниже.

Базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана только для получения эталонных метрик для сравнения, кроме того, настоящая производственная нагрузка никогда не настраивается с FTT=0 (количество допустимых отказов) и без RAID (то есть без защиты).

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

Детали виртуальной машины "Oracle21C-OL8-DB_ESA" показаны на картинке ниже.

Виртуальная машина имеет 28 vCPU, 256 ГБ RAM. Один экземпляр базы данных "ORA21C" был создан с опцией multi-tenant на базе инфраструктуры Oracle Grid (ASM). Версия базы данных - 21.13 на операционной системе OEL UEK 8.9.

Oracle ASM использовалась как платформа хранения данных с Linux udev для обеспечения персистентности устройств. Oracle SGA и PGA были установлены на 64G и 10G соответственно. Также были соблюдены все лучшие практики платформы Oracle на VMware.

Виртуальная машина "Oracle21C-OL8-DB_ESA" имеет 4 контроллера vNVMe для дополнительной производительности:

58 устройств хранения привязаны к ВМ "Oracle21C-OL8-DB_ESA", они показаны ниже:

• NVME 0:0 – 80G для OS (/)
• NVME 0:1 – 80G для Oracle Grid и бинарников RDBMS
• NVME 0:2 – 100G для GRID_DG
• NVME 0:3 – 200G для DATA_DG
• NVME 0:4 – 200G для DATA_DG
• NVME 0:5 – NVME 0:12 – 8 дисков vmdk, каждый 25 ГБ – REDO_DG
• NVME 1:0 – 1:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 2:0 – 2:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG
• NVME 3:0 – 3:14 – 15 дисков vmdk, каждый 50 ГБ – SLOB_DG

Детали тестов разных политик хранения vmdk для ВМ "Oracle21C-OL8-Customer" показаны ниже:

• Тест 1 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT0 – NoRAID"
• Тест 2 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT1 – R5"
• Тест 3 – Прогон теста со всеми vmdk с политикой хранения "Oracle ESA – FTT2 – R6"

Детали группы дисков Oracle ASM показаны ниже:

Тестовый сценарий

Результаты ниже являются тестовым сценарием, демонстрирующим преимущества производительности использования vSAN 8 vSAN Express Storage Architecture (ESA) для бизнес-критичных производственных нагрузок Oracle.

Генератор нагрузки SLOB был запущен против 2 TB табличного пространства SLOB с 3 различными политиками хранения.

• Oracle ESA – FTT0 – NoRAID
• Oracle ESA – FTT1 – R5
• Oracle ESA – FTT2 – R6

В качестве генератора нагрузки для этого эксперимента был выбран SLOB 2.5.4.0 с следующими установленными параметрами SLOB:

UPDATE_PCT=30
RUN_TIME=300
SCALE=25G
WORK_UNIT=1024

Для имитации модели нагрузки с многосхемной работой использовались несколько схем SLOB, и количество потоков на схему было установлено в 20.

Размер рабочего блока был установлен в 1024 для максимизации объема ввода-вывода без перегрузки REDO для изучения различий в показателях производительности между 3 различными политиками хранения на vSAN ESA.

В VMware провели несколько прогонов SLOB для вышеупомянутого кейса и сравнили метрики Oracle, как показано в таблице ниже.

Напомним, что базовая политика Oracle "Oracle ESA – FTT0 – NoRAID" была создана ИСКЛЮЧИТЕЛЬНО для получения базовых метрик для сравнения, так как настоящая производственная нагрузка никогда не настраивается с FTT=0 и без RAID.

Мы видим, что метрики базы данных с новым высокопроизводительным кодированием RAID 5/6 архитектуры vSAN Express Storage Architecture (ESA) сопоставимы с базовыми показателями при использовании без RAID.

Как было сказано ранее, клиенты могут ожидать, что RAID-5/6 будет работать наравне с RAID-1 при использовании vSAN ESA. Новая архитектура обеспечит оптимальные уровни устойчивости, а также эффективность с точки зрения использования пространства.

Углубляясь в профили нагрузки основных баз данных, мы видим схожие метрики баз данных для исполнений запросов (SQL), транзакций, чтения/записи в IOPS и чтения/записи в МБ/сек как для прогонов политик хранения "Oracle ESA – FTT1 – R5", так и для "Oracle ESA – FTT2 – R6", а именно:

• Выполнение запросов (SQL) в секунду и транзакции в секунду сопоставимы для всех трех прогонов
• Запросы на чтение IO в секунду и запросы на запись IO в секунду сопоставимы для всех трех прогонов
• Чтение IO (МБ) в секунду и запись IO (МБ) в секунду сопоставимы для всех трех прогонов

Углубляясь в изучение основных событий ожидания (wait events) базы данных, мы видим схожие события ожидания базы данных с похожими временами ожидания (wait times) для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Рассматривая статистику GOS, мы также можем видеть сопоставимые показатели производительности для запусков политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6":

В итоге нам удалось получить сопоставимые показатели производительности как с общей точки зрения базы данных, так и с точки зрения GOS для прогонов политик хранения "Oracle ESA – FTT1 – R5" и "Oracle ESA – FTT2 – R6".

Продолжаем рассказывать о решении VMware vSAN Max, которое было анонсировано в рамках конференции VMware Explore 2023 в августе прошлого года.

Решение vSAN Max, работающее на архитектуре vSAN Express Storage - это новое предложение в семействе vSAN, которое позволяет получить модель развертывания на базе подписки для отдельных хранилищ, объединяющих петабайты информации на платформе vSphere. Используя vSAN Max в рамках отдельных или растянутых кластеров, пользователи могут масштабировать хранилище независимо от вычислительных мощностей для повышения уровня гибкости при поддержке всех своих рабочих нагрузок. Новое предложение vSAN Max лицензируется отдельно от существующих версий vSAN.

VMware vSAN Max показывает значительный прогресс в гиперконвергентной инфраструктуре (HCI) и решает проблемы хранения данных, с которыми администраторы сталкиваются в современном цифровом мире. Построенный на архитектуре хранилища Express Storage Architecture (ESA) от VMware, vSAN Max предлагает дизагрегированное HCI-решение для хранения данных в масштабах петабайт. Оно обеспечивает беспрецедентный уровень масштабируемости, гибкости и экономичности хранения для ИТ-инфраструктур.

Проблемы современных хранилищ данных

1. Масштабируемость и гибкость

Современные предприятия полагаются на разнообразные приложения, каждое из которых имеет уникальные потребности в ресурсах. Широкий спектр приложений и их разные требования к масштабированию добавляют сложности, создавая необходимость в инфраструктуре, которая была бы способна быстро расти и адаптироваться к меняющимся требованиям.

2. Управление затратами

Балансировка высокой производительности с экономией затрат крайне важна, поскольку бизнесы стремятся оптимизировать расходы на ИТ, не жертвуя качеством, особенно для критичных приложений.

3. Требования к производительности

Растущая сложность и объем рабочих нагрузок с большим объемом данных требуют гибкой инфраструктуры, способной эффективно поддерживать критичные массивные приложения.

4. Простота и эффективность

Управление изолированной ИТ-инфраструктурой может затруднить операционную эффективность, что создает необходимость в более простых решениях для управления виртуальной средой.

VMware vSAN Max: решение для современных вызовов в ИТ

VMware vSAN Max разработан для успешного преодоления этих вызовов, предлагая решение HCI с изолированными хранилищами, которое позволяет независимо масштабировать ресурсы хранения от ресурсов вычислений. Он позволяет бизнесам быстро адаптироваться к изменяющимся потребностям, гарантируя, что возможности хранения точно соответствуют спросу на эти ресурсы. Эта адаптивность поддерживает динамические рабочие нагрузки и рост, значительно улучшая гибкость и масштабируемость ИТ-инфраструктуры.

Преимущества VMware vSAN Max:

• Эластичное и независимое масштабирование ресурсов хранения

vSAN Max позволяет пользователям динамически корректировать объем хранения в соответствии с изменяющимся спросом на ресурсы. Он поддерживает расширение ресурсов хранения HCI, позволяя масштабировать до более чем 8.5 петабайт в пределах кластера. Каждый узел vSAN Max может поддерживать до 360 ТБ на хост, достигая плотности хранения до 7 раз выше, чем у традиционных узлов HCI.

• Снижение стоимости владения

vSAN Max предлагает снижение общей стоимости владения до 30% для критически важных приложений благодаря оптимизированной эффективности работы с ресурсами и максимальному использованию оборудования.

• Исключительная производительность

Построенный на основе vSAN ESA, vSAN Max оснащен для управления огромными объемами данных и удовлетворения строгих требований к производительности и надежности. Он может обеспечивать до 3.6 миллионов операций ввода-вывода в секунду (IOPS) на кластер хранения, обеспечивая плавную работу приложений с высокими требованиями к хранилищу.

• Упрощенное администрирование

vSAN Max нативно интегрируется с гипервизором VMware vSphere, предоставляя единый опыт управления через vSphere Client. Он включает отдельные разделы интерфейса пользователя для развертывания и мониторинга, тем самым уменьшая зависимость от нескольких консолей управления и упрощая административные задачи.

VMware vSAN улучшает возможности хранения VMware vSphere и VMware Cloud Foundation с введением vSAN Max как опциональной модели разделенного развертывания HCI. vSAN Max повышает эффективность управления виртуальными машинами с высокой нагрузкой на подсистему хранения в среде HCI, позволяя независимо масштабировать хранилище. Эта оптимизация использования ресурсов не только снижает затраты, но и обеспечивает уровень масштабируемости, гибкости и производительности, отвечающий требованиям современных бизнесов.

Основные технические подробности о vSAN Max рассмотрены в видео ниже:

Больше интересного о VMware vSAN Max вы можете найти по следующим ссылкам:

• Какие функции Datastore Sharing/HCI Mesh/vSAN Max поддерживаются для растянутых кластеров?
• Гибкие сетевые топологии растянутых кластеров в решении VMware vSAN Max
• Анонсы VMware Explore 2023: vSAN 8 Update 2 и vSAN Max
• Сайзинг пропускной способности соединения между площадками для растянутого кластера vSAN Stretched Cluster
• ReadyNode Profiles Certified for vSAN Max
• Introducing vSAN Max
• vSAN Frequently Asked Questions (FAQ)
• vSAN Max Configuration

На днях компания VMware выпустила обновления для своей флагманской платформы VMware vSphere 8 Update 2 - ESXi 8.0 Update 2b и vCenter 8.0 Update 2b.

Что нового появилось VMware ESXi 8.0 Update 2b:

• 100 GiB пробной емкости хранения на каждое ядро vSAN - начиная с vSphere 8.0 Update 2b, в рамках предложения VMware vSphere Foundation, вы можете использовать до 100 гибибайт (GiB) хранилища vSAN на каждое лицензированное ядро хоста vSAN без применения лицензионного ключа vSAN. Для емкости, превышающей 100 GiB на каждое ядро vSAN, вы можете приобрести емкость vSAN на тебибайт (TiB) и применить ключ vSAN, отражающий общую сырую емкость хранилища кластера vSAN. Для получения дополнительной информации о отчетах по емкости и лицензировании vSAN смотрите "Разъяснение отчетности по емкости в vSAN" и "Подсчет ядер для VMware Cloud Foundation и vSphere Foundation и TiB для vSAN".
• Добавлена поддержка технологии vSphere Quick Boot для множества серверов: 
  • Dell - MX760c vSAN Ready Node, PowerEdge C6615, PowerEdge XR8610t, R7625 vSAN Ready Node, VxRail VP-760xa, VxRail VS-760
  • HPE - Alletra Storage Server 4110/4140, Cray XD670, ProLiant DL110 Gen11/DL20 Gen11/ProLiant ML30 Gen11
  • Lenovo DN8848 V2
• Исправлена ошибка с необнаружением Apple NVMe на Apple Mac Mini 2018. Об этом написал Вильям Лам.

Более подробно об обновлении VMware ESXi 8.0 Update 2b написано в Release Notes.

Что нового появилось VMware vCenter Server 8.0 Update 2b:

• Агрегация статистики по GPU на уровне хоста и кластера - в этом обновлении vCenter вы можете отслеживать агрегацию метрик GPU на уровне хоста и кластера, что полезно для нагрузок генеративного искусственного интеллекта, традиционных нагрузок AI и других, ускоренных с помощью GPU. В клиенте vSphere, в разделе Monitor > Performance, вы увидите:
  • на уровне хоста: обзорные диаграммы производительности и расширенные диаграммы производительности для использования вычислений на GPU, распределения памяти и температуры на хостах.
  • на уровне кластера: расширенные диаграммы производительности с агрегированной статистикой от хостов для памяти GPU и использования GPU.
• Для получения дополнительной информации смотрите "Работа с расширенными и пользовательскими диаграммами" и "Обзорные диаграммы производительности".
• Обновления vSphere with Tanzu (подробности тут) и Photon OS (подробности здесь).

Более подробно об обновлении vCenter Server 8.0 Update 2b написано в Release Notes.

Скачать VMware vSphere 8 Update 2, включая ESXi 8.0 Update 2b и vCenter Server 8.0 Update 2b можно по этой ссылке.

Пару лет назад мы писали о производительности Microsoft SQL Server в облаке VMware Cloud on AWS для инстанса AWS-i4i.metal. С тех пор много что изменилось, а компания VMware анонсировала новый тип экземпляра m7i для VMware Cloud на AWS, который использует сетевое хранилище NFS вместо vSAN. Это предоставляет клиентам гибкое и масштабируемое хранилище на основе VMware Cloud Flex Storage и Amazon FSx для NetApp ONTAP.

Для других типов экземпляров VMware Cloud на AWS включено хранилище vSAN, которое базируется на локальных дисках каждого хоста. Хранилища данных vSAN растут вместе с кластером по мере добавления новых узлов. С m7i количество хранилища не зависит от числа хостов, и вы можете настроить его в зависимости от требований к хранилищу.

Ниже рассмотрим производительность виртуальных машин SQL Server, работающих на 3-узловом кластере m7i с хранилищем NFS, по сравнению с 3-узловым кластером i4i с хранилищем vSAN. Инстансы m7i основаны на процессорах Intel, которые на одно поколение новее, чем i4i. Вот чем отличаются эти инстансы:

Методология

Для тестов использовался набор ВМ с 16 vCPU и 24 vCPU. Поскольку экземпляры m7i имели 48 ядер, как 16 vCPU, так и 24 vCPU были равномерно распределены по общему количеству ядер, что облегчало сравнение производительности и делало его понятным. Для поддержки максимального числа ВМ с 16 vCPU на кластере m7i каждой ВМ назначили 60 ГБ ОЗУ.

Для тестов использовали ВМ Windows Server 2022 с установленным Microsoft SQL Server 2022 и применили открытый инструментарий бенчмаркинга DVD Store 3.5 для запуска нагрузок OLTP-приложений на SQL Server и измерения результатов. DVD Store симулирует онлайн-магазин, где клиенты просматривают, оставляют отзывы и оценивают, регистрируются и покупают продукты. Результаты выражаются в заказах в минуту (OPM), что является мерой пропускной способности. Чем выше показатели OPM - тем лучше.

Результаты производительности ВМ SQL Server с 24 vCPU против 16 vCPU

Результаты на рисунках 1 и 2 показывают производительность ВМ с 24 vCPU и 16 vCPU. Линия обозначает общую пропускную способность в OPM по всем ВМ в каждом тесте. Количество ВМ увеличивается в каждом тесте, начиная с 1 и заканчивая максимально возможным, исходя из количества vCPU, соответствующих числу доступных потоков в кластере.

Темп прироста OPM замедляется, когда количество vCPU превышает количество физических ядер и необходимо использовать второй логический поток (hyperthread) на каждом ядре. Это начинается с 8 и 12 ВМ для тестов с 24 и 16 vCPU соответственно.

Столбцы в каждом графике представляют использование CPU трех хостов для каждого теста. По мере добавления ВМ, VMware Distributed Resource Scheduler (DRS) автоматически размещал и, возможно, динамически перемещал ВМ между хостами для управления нагрузкой. Как показывают результаты, это поддерживало использование CPU на всех хостах довольно стабильным, даже когда нагрузка увеличивалась.

Последняя точка данных в тесте с 16 vCPU (рисунок 2) показывает небольшое снижение OPM, поскольку на этом этапе теста кластер немного перегружен. Несмотря на это, можно было продолжить масштабирование производительности кластера m7i, добавляя больше инстансов. В этих тестах был использован только кластер из 3 инстансов, но можно было бы добавить больше инстансов в кластер для увеличения его емкости.

Рисунок 1 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 24 vCPU на ВМ:

Рисунок 2 - производительность виртуализированного SQL Server и использование CPU ESXi для кластера из 3 хостов VMware Cloud на AWS с 16 vCPU на ВМ:

Рисунок 3 сравнивает производительность ВМ с 16 vCPU и 24 vCPU таким образом, что в каждом тестовом случае назначалось одинаковое общее количество vCPU. Например, для 48 vCPU 2?24 vCPU сравниваются с 3?16 vCPU (по сумме - 48 в обоих случаях).

Рисунок 3 - производительность ВМ SQL Server: 16 vCPU по сравнению с 24 vCPU:

Сравнение производительности m7i с i4i

Те же ВМ были перенесены на кластер i4i и тесты повторили. Важно отметить, что чтобы сохранить ВМ максимально идентичными, им не увеличивали объем RAM, несмотря на то, что в кластере i4i было примерно в 2,5 раза больше RAM.

Как показывает рисунок 4, результаты для i4i были схожи в плане OPM и использования CPU хоста. Основное отличие: получилось запустить до 24 ВМ на i4i против максимума 18 ВМ на m7i. Это связано с большим количеством ядер и большей памятью в экземплярах i4i.

Рисунок 4 - трехузловой кластер i4i VMware Cloud on AWS: SQL Server ВМ и использование CPU хоста на ВМ с 16 vCPU по сравнению с vSAN:

Рисунок 5 показывает различия между m7i и i4i. Поскольку отдельные ядра экземпляров m7i имеют более высокую производительность, чем ядра кластера i4i, рисунок 5 показывает преимущество в производительности на левой стороне графика. Как только экземплярам m7i необходимо полагаться на второй логический поток (hyperthread) от каждого физического ядра для поддержки рабочих нагрузок, производительность i4i становится схожей. И, наконец, когда экземпляры i4i полностью используют преимущество большего количества ядер, их производительность превышает производительность m7i.

Рисунок 5 - различие между m7i и i4i:

Тестирование производительности говорит о хорошей работе SQL Server на m7i в рамках предоставляемой экземплярами m7i ресурсной емкости. Поскольку экземпляры m7i имеют меньше ядер и меньше памяти, чем i4i, важно использовать инструмент VMC Sizer, чтобы убедиться, что платформа соответствует потребностям баз данных.

Также наблюдались немного более высокие задержки с подключенным к m7i хранилищем NFS, но в целом это не оказало большого влияния на результаты тестов. Важно также правильно подобрать хранилище NFS, подключенное к m7i, и установить для хранилища IOPs и пропускную способность на уровни, соответствующие требованиям рабочей нагрузки.

Недавно компания VMware представила очередной релиз платформы виртуализации и доставки настольных ПК и приложений Horizon 8 2312, в котором появилось несколько функций, разработанных для улучшения опыта работы как администраторов, так и конечных пользователей. Horizon 2312 предлагает набор возможностей, направленных на оптимизацию операций, обеспечение безопасности сессий, повышение производительности и добавление большей персонализации к каждой сессии. Напомним, что о прошлой версии VMware Horizon 8 2306 мы рассказывали вот тут.

Horizon 2312 является последним релизом ветки Extended Service Branch (ESB) - это означает, что VMware предоставит несколько будущих обновлений, содержащих критические исправления ошибок и поддержку новых версий ОС в течение трехлетнего периода. Более подробно об этом рассказано здесь.

Давайте посмотрим, что нового в Horizon 2312:

Улучшения клиента и агента Horizon

Во-первых, давайте рассмотрим все улучшения, внесенные в Horizon Agent и Client, которые повышают производительность и персонализацию для конечного пользователя, а также оптимизируют безопасность и операции для ИТ.

1. Автоматическое обновление агента Horizon для упрощения обслуживания

Вы можете оптимизировать ваши Day-2 операции с помощью активной технологии виртуального рабочего стола (VDI), используя функцию auto-upgrade для агента Horizon, которая автоматизирует обновления по всем вашим VDI или RDSH десктопам, убирая необходимость в ручных обновлениях. Эта функция доступна эксклюзивно для клиентов с лицензией Horizon Plus или Horizon Universal и применима для рабочих столов Full Clone и серверов RDSH. Для обновления агента Horizon в пулах мгновенных клонов или фермах удаленных рабочих столов (RDS) просто обновите агент Horizon в золотом образе и запланируйте окно технического обслуживания для развертывания нового образа.

2. Оптимизированная производительность CPU

Протокол Blast продолжает повышать производительность удаленных рабочих столов за счет оптимизации операций с процессором. Регулируя частоту кадров, CPU умно управляет тем, когда и как применяется увеличенная вычислительная мощность, обеспечивая лучшую плотность ВМ и производительность. Это не только улучшает эффективность использования ресурсов, но и делает опыт конечных пользователей более комфортным.

3. Улучшенные изображения с бинарным lossless-режимом для кодека Blast

Horizon 2312 вводит бинарный lossless-режим для кодека Blast. Он делает так, что при сжатии изображений не теряется ни одна деталь — обеспечивая пиксель-к-пикселю воссоздание оригинального изображения. Эта функция обеспечивает максимальную четкость изображения, гарантируя, что конечные пользователи получают лучший опыт использования. С бинарным lossless-режимом Blast пользователи в критически важных областях, таких как здравоохранение, могут быть уверены, что их изображения, включая рентгеновские снимки и другие детализированные сканы, передаются без потери информации.

4. Увеличение персонализации с помощью настраиваемых фонов Microsoft Teams

Horizon 2312 получил новую функцию, позволяющую ИТ-администраторам загружать подборку одобренных фонов для Microsoft Teams, включая фирменные или другие тематические фоны. С этим обновлением конечные пользователи могут выбирать из этих предварительно одобренных фонов для настройки своего виртуального пространства для встреч, обеспечивая более персонализированный подход при сохранении профессионального вида.

5. Размытие фона для клиента Linux

Этот выпуск вводит возможность размывать фон во время встреч в Microsoft Teams для клиентов Linux. Это улучшение повышает качество встреч для конечных пользователей, предлагая слой конфиденциальности и минимизируя отвлекающие факторы.

6. Модуль FIPS для MacOS

Для клиентов, требующих модуль обработки федеральных стандартов информации (FIPS) для macOS, клиент Horizon MacOS использует шифры, соответствующие FIPS.

7. Упрощенное развертывание Horizon Linux с помощью инструмента легкой настройки

Horizon 2312 получил легкую настройку для агента Horizon Linux. Этот новый инструмент предназначен для упрощения процесса установки с помощью CLI-инсталлятора и руководства администратора. Он предлагает пошаговый подход к развертыванию агента Horizon Linux, облегчая более гладкую и эффективную настройку. С помощью инструмента легкой настройки администраторы ИТ теперь могут без труда устанавливать агент, упрощая и обеспечивая успешное развертывание в операционной системе Linux.

8. Улучшения режима эмуляции, совместимого с ARM, для клиента Windows

На основе релиза Horizon 2309, который добавил поддержку режима эмуляции, совместимого с устройствами на базе ARM, решение Horizon 2312 предоставляет дополнительную функциональность с поддержкой «Login as Current User» (LACU). Эта функция, эксклюзивная для Windows, упрощает рабочие процессы для устройств, входящих в домен, используя функциональность LACU, чтобы позволить пользователям запускать Horizon без необходимости повторной аутентификации. Поддержка Horizon для ARM предоставляет клиентам больше выбора оборудования для их конечных пользователей, предлагая больше вариантов аппаратного обеспечения и обеспечивая операционную эффективность.

9. Возможность блокировки SendKey для защиты ВМ от вредоносных скриптов

Horizon 2312 вводит возможность блокировать скрипты PowerShell и другие скрипты SendKey от передачи с устройства пользователя в виртуальную машину. Блокируя скрипты от отправки вредоносных нажатий клавиш, эта функция предотвращает манипуляции злоумышленников с сессией конечного пользователя. Доступная для Horizon Client for Windows, эта защитная мера помогает предотвратить потенциальные атаки типа "отказ в обслуживании" (DoS) и внедрение вредоносного программного обеспечения, обеспечивая безопасность виртуальных сессий.

10. Интеграция DEEM улучшает возможности телеметрии Horizon

Horizon интегрировал возможности управления цифровым опытом сотрудников (DEEM) для улучшения аналитики по опыту сотрудников. Horizon будет предоставлять информацию, связанную с сессией, агенту DEEM, оптимизируя сбор и передачу телеметрии ВМ внутри гостевой системы напрямую в Workspace ONE Intelligence. С этим обновлением агент Horizon делится телеметрией гостевой ОС — такой как ID сессии Horizon, ID пула и имя пула — с агентом DEEM, предоставляя набор данных, доступных для анализа. Собранная информация о производительности ВМ и опыте пользователя позволяет администраторам превентивно решать проблемы, оптимизировать ресурсы и улучшать общий опыт пользователя. Эта интеграция DEEM и агента Horizon в настоящее время находится в бета-тестировании до конца марта 2024 года. Если вы заинтересованы в участии в бета-программе, то можно зарегистрироваться тут.

Новые возможности платформы Horizon 2312

Теперь, когда мы рассмотрели все новшества в клиентах и агентах Horizon, давайте обсудим новые функции платформы, которые подтверждают приверженность VMware улучшению операций, обеспечению безопасности взаимодействий пользователей и расширению возможностей для удовлетворения потребностей администраторов.

1. Права доступа Horizon Cloud

Horizon 2312 позволяет конечным пользователям получать права доступа как из Horizon 8, так и из Horizon Cloud Service (HCS). Пользователи могут входить в локальный сервер подключения Horizon с использованием своих учетных данных без необходимости повторного входа для доступа к тем же правам на рабочие столы и приложения в облаке. Эта интеграция устраняет необходимость в использовании множества URL, выходов и дополнительных входов в систему при переключении между локальными и облачными рабочими столами, синхронизируя права доступа в обеих средах. Конечные пользователи могут аутентифицироваться через клиент Horizon для Windows или HTML Access, получить свои права Horizon 8 и затем получить доступ к своим правам Azure в Horizon Cloud Next-Gen с использованием токена JWT. Для получения дополнительной информации обращайтесь сюда.

2. Интуитивно понятный графический интерфейс для функции форензики

На основе функции форензики, представленной в релизе Horizon 2206, которая позволяет сохранять непостоянные ВМ для последующего просмотра, Horizon 8 теперь добавил графический пользовательский интерфейс (GUI). Специально разработанный для рабочих столов Instant Clone, этот интуитивно понятный графический интерфейс предоставляет информацию, связанную с пользователем, и детали форензических действий внутри ВМ. Новый графический интерфейс служит мостом, добавляя видимость и простоту к процессам расследований в виртуальных средах.

Функции форензики могут быть применены к пользователям или группам:

Отдельные машины пользователя или группы можно выбрать для более детального изучения:

3. Оптимизированная база данных ADAM для улучшения производительности репликации

В связи с ростом баз данных Active Directory Application Mode (ADAM), Horizon 2312 предлагает решение, направленное на уменьшение размера базы данных за счет сокращения периода "tombstone-lifetime" для уменьшения времени репликации. Ранее удаленные объекты сохранялись в течение 180 дней, что приводило к увеличению базы данных и удлинению времени репликации. В версии 2312 этот период сокращается до 60 дней, что приведет к уменьшению размера базы данных, ускорению репликации и повышению надежности работы системы. Кроме того, это помогает сократить время, необходимое для полной репликации базы данных ADAM, например, при добавлении Connection Server в существующую среду.

4. Настройка маршрутизации RDSH для опубликованных приложений и рабочих столов

Для предоставления администраторам более точного контроля во время тестирования и устранения неполадок, Horizon 2312 позволяет использовать опубликованные приложения и рабочие столы для направления пользователей на конкретные RDSH в рамках фермы. Эта функциональность сделана в ответ на потребности заказчиков — будь то для проверки и мониторинга всего процесса end-to-end или для проведения теста на каждом RDSH внутри фермы. Эта функция активируется в настройках опубликованного приложения или рабочего стола и требует использования параметра командной строки клиента Horizon для Windows. Функция также доступна для выбора конкретной виртуальной машины из пула non-persistent рабочих столов.

5. Автоматизированное обслуживание мгновенных клонов с автоматическим отключением хостов RDS

В обновлении Horizon 2313 автоматически отключаются отдельные хосты RDS в фермах мгновенных клонов RDS при выполнении обслуживания и использовании опции "Wait for users to logoff". Ранее администраторам приходилось вручную вмешиваться, чтобы отключить хосты для обслуживания. Теперь система автоматизирует этот процесс, оставляя достаточное количество хостов RDS включенными для поддержания доступа пользователей, позволяя другим хостам RDS освобождаться и обновляться.

6. Политика приостановки питания для мгновенных клонов с vGPU

Применение политик управления питанием полезно для экономии ресурсов, когда ВМ не используются. В Horizon 2312 администраторы могут использовать политику приостановки удаленной машины для пулов мгновенных клонов с поддержкой NVIDIA vGPU. Эта функция активируется ESXi, который поддерживает политики приостановки/возобновления питания для ВМ с vGPU. Отметим, что только версии ESXi 6.7 или выше поддерживают эту функцию.

7. Настройка текста запроса на сброс пароля в консоли администратора

Для улучшения соответствия протоколам безопасности организации, Horizon 2312 вводит возможность для администраторов отображать настраиваемые сообщения политики во время операций сброса пароля. Это обновление, доступное из консоли администратора, помогает снизить количество неудачных попыток сброса пароля, предоставляя пользователям четкие напоминания о требованиях к политике паролей. Когда пользователи пытаются изменить свои пароли, и выбранный пароль не соответствует установленным критериям, система теперь представит настроенное сообщение, описывающее конкретные требования к паролю.

Настроенное сообщение будет показано при неудачной попытке изменения пароля:

8. Завершена модернизация API с полным переходом на REST

Horizon 2312 завершает переход с API, основанных на SOAP, на REST API с полным сохранением функциональности предыдущих SOAP API. Все новые RESTful API можно загрузить с сайта API сервера Horizon.

9. Архитектура vSAN Express Storage

Horizon 8 2309 начал поддерживать vSAN 8 Express Storage Architecture (ESA) как для полных, так и для мгновенных клонов. Сейчас эта поддержка была улучшена. vSAN ESA — это новая, опциональная архитектура хранения, введенная в vSAN 8. Кроме того, с этой новой поддерживаемой архитектурой, Horizon может поддерживать до 500 ВМ на хост ESXi в зависимости от рабочей нагрузки и конфигурации оборудования. vSAN 8 предоставляет клиентам свободу выбора, какую из двух архитектур (vSAN OSA или vSAN ESA) использовать, чтобы лучше всего удовлетворить их потребности. vSAN ESA обеспечивает новые уровни производительности, масштабируемости, надежности и простоты использования на базе высокопроизводительных устройств хранения. Чтобы узнать больше почитайте вот эту статью блога VMware.

На этом обзор основных моментов релиза Horizon 2312 закончен. Для полного ознакомления со всеми улучшениями обратитесь к Horizon 8 2312 Release Notes.

VMware Cloud Foundation (VCF) — это решение для частного облака от Broadcom, основанное на виртуализации вычислений, сетевых функций и хранилищ, предоставляющее клиентам возможность реализации модели облачной операционной системы на онпремизных площадках клиентов (более подробно об этом тут, тут и тут). Оно предлагает такие преимущества, как простота развертывания и управление жизненным циклом с использованием предварительно проверенного списка ПО (Bill of Materials, BOM), который тщательно тестируется на совместимость.

Хранение данных (критически важная часть частного облака) поддерживается в двух категориях: Основное (Principal) и Дополнительное (Supplemental).

Основное хранилище (Principal Storage)

Основное хранилище настраивается при создании нового домена рабочей нагрузки (Workload Domain) или кластера в консоли SDDC Manager. После создания тип основного хранилища для кластера изменить нельзя. Однако Workload Domain может включать несколько кластеров с собственными типами основного хранилища.

Основные варианты хранения данных (principal storage) включают:

• vSAN
• vVols
• NFSv3
• VMFS на FC-хранилищах

Следует отметить, что vSAN является единственно поддерживаемым типом основного хранилища для всех кластеров в управляющем домене (Management Domain). vSAN требуется для управляющего домена, поскольку он предсказуем с точки зрения производительности. vSAN предоставляет высокопроизводительное решение для хранения данных Enterprise-уровня для SDDC. Использование vSAN исключает внешние зависимости и облегчает использование средств автоматизации для инициализации управляющего домена VCF. Во время первоначальной установки VCF Cloud Builder инициализирует все основные компоненты центра обработки данных, определяемые программно - такие как vSphere, NSX и vSAN, на минимально необходимом количестве хостов. Этот процесс первоначального запуска в среднем занимает около двух часов.

Дополнительное хранилище (Supplemental storage)

Supplemental storage предоставляет дополнительную емкость кластеру и рекомендуется для данных Tier-2 или Tier-3, таких как библиотеки контента vSphere, шаблоны виртуальных машин, резервные копии, образы ISO и т. д. Дополнительное хранилище требует ручной настройки, не интегрировано и не отображается в SDDC Manager.

Доступные варианты таких хранилищ включают vSAN, vVols, VMFS на FC или iSCSI, NFSv3 или v4.1, а также NVMe-FC или NVMe-TCP.

Роль vSAN ESA

Начиная с версии 5.1, vSAN поддерживает как OSA (оригинальная архитектура хранения), так и ESA (экспресс архитектура хранения). vSAN ESA оптимизирован для использования с высокопроизводительными устройствами хранения нового поколения на базе NVMe, чтобы обеспечить еще более высокие уровни производительности для требовательных рабочих нагрузок, таких как OLTP и генеративный AI. Broadcom рекомендует использовать vSAN ESA в качестве основного хранилища для всех доменов рабочих нагрузок, чтобы получить все преимущества управления и обслуживания полностью программно-определенного стека.

vSAN также обновляется и патчится через LCM (Lifecycle Manager) в SDDC Manager. Обновление и патчинг хранилищ, отличных от vSAN, является ручной задачей и не входит в процедуры управления жизненным циклом, реализованные в SDDC Manager. Для обеспечения поддержки, само хранилище и его HBA необходимо проверять на соответствие VMware Compatibility Guide, когда vSAN не используется.

vSAN использует движок Storage Policy-Based Management (SPBM), который позволяет управлять политиками хранения на уровне виртуальных машин, а не на уровне всего хранилища (datastore). С помощью этого механизма вы можете управлять всеми хранилищами инфраструктуры VCF. Если у вас большая инфраструктура, то необходимо использовать программные средства автоматизации, так как вручную управлять LUN и виртуальными томами и их возможностями очень проблематично в большом масштабе.

Также на эту тему есть интересная статья: "Why vSAN and vVols are Best for VMware Cloud Foundation".

Выводы

vSAN является рекомендуемым решением для хранения данных рабочих нагрузок по вышеупомянутым причинам. Однако VMware понимает, что среды разных клиентов не идентичны, и единый для всех подход не работает. Именно поэтому VCF поддерживает разнообразие типов основного и дополнительного хранилища. Эта гибкость с другими вариантами хранения предоставляет клиентам свободу выбора и позволяет VCF удовлетворить разнообразные потребности производственных сред клиентов.

Важно понимать широкий спектр требований, таких как производительность, доступность, емкость, ожидаемый рост и инвестиции в существующую инфраструктуру. В этой связи для получения дополнительной информации о VMware Cloud Foundation и требованиях к хранилищу, пожалуйста, обратитесь к следующим ресурсам:

• VMware Cloud Foundation Resource Center
• vSAN ReadyNode Sizer
• Why vSAN and vVols are Best for VMware Cloud Foundation

VMware Cloud Foundation 5.1 и vSAN 8 Update 2 вносят новые улучшения в архитектуру хранения данных vSAN Express Storage Architecture (ESA), которые помогают лучше понять потребление емкости в кластерах.

Часто задаваемые вопросы администраторов

Когда речь идет о хранении данных, основные вопросы, которые задают себе архитекторы центров обработки данных - это "сколько емкости хранения я купил?", "сколько я использую?" и "сколько у меня осталось?". Хотя ответы кажутся очевидными, системы хранения данных часто полагаются на множество способов обеспечения надежности данных и часто используют возможности повышения эффективности использования пространства, что иногда может затруднить ответы на эти вопросы.

Стек хранения данных ESA обрабатывает и хранит данные иначе, чем Original Storage Architecture (OSA). В результате, его накладные расходы на хранение метаданных, файловых систем и необходимая емкость для обеспечения надежности хранения основных данных на случай сбоя также отличаются. Недавние улучшения в vSAN 8 U2 и VMware Cloud Foundation 5.1 включают изменения в пользовательском интерфейсе, которые позволяют лучше учитывать эти накладные расходы. Эти улучшения упрощают понимание потребления емкости. Давайте посмотрим, что изменилось и рассмотрим пример использования емкости хранения для ESA.

Пример потребления храненилищ в ESA

Кластер в примере ниже состоит из 8 хостов ESXi, работающих на платформе vSAN 8 U2. Каждый хост оснащен четырьмя устройствами хранения емкостью 1.6 ТБ, обеспечивая чуть менее 6 ТБ на хост или примерно 47 ТБ для кластера. В этом кластере ESA работает около 100 виртуальных машин, каждой из которых назначена специфичная для кластера политика хранения данных по умолчанию с RAID-6 под управлением функции автоматического управления политиками vSAN ESA. Также там включена функция возврата пространства хранилищ TRIM/UNMAP vSAN. Для ясности, в этом кластере не включены механизмы управления емкостью операционного резерва и резерва восстановления хоста (Operation's Reserve и Host Rebuild Reserve). Хотя этот пример использует кластер в варианте развертывания vSAN HCI, результаты будут такими же, как и в кластере, работающем на vSAN Max.

vSAN представляет емкость кластера на странице Summary, которая делится на два раздела. Раздел "Capacity Overview" показывает, сколько доступной емкости используется, а "Usage breakdown" подробно описывает тип данных, в настоящее время хранящихся в кластере.

Представление Capacity Overview

В этом примере пользовательский интерфейс показывает, что кластер предоставляет 46.57 ТБ отформатированной сырой емкости. Маленькая вертикальная линия на графике обзора емкости представляет "порог операций" (operations threshold), который отражает рекомендуемый лимит потребления емкости (в данном случае - 38.27 ТБ), который обеспечивает операционную деятельность vSAN.

Хотя на кластере хранится почти 31 ТБ данных гостевых виртуальных машин, метаданных объектов и снимков, фактически используемая емкость составляет 17.69 ТБ после учета сжатия данных, что экономит 13.70 ТБ. Сжатие данных в ESA гораздо лучше, чем в OSA, но, конечно, коэффициенты сжатия, которых вы достигнете, будут полностью зависеть от типа данных, хранящихся в вашей среде.

Представление Usage breakdown

В разделе "Usage breakdown" подробно описывается распределение данных после сжатия, исключая свободную емкость. Нововведением в vSAN 8 U2 и VMware Cloud Foundation является значение "ESA object overhead" в категории "System usage". Она отображает метаданные, создаваемые в отношении объекта и реплицированных данных. В этом примере оно составляет около 11.96% от хранимых данных. Указанные накладные расходы объекта ESA рассчитываются после сжатия данных, так что чем лучше сжатие, тем меньше необходимо накладных расходов.

Рекомендация: используйте представление "Usage breakdown" только для хорошо заполненных кластеров. Поскольку расчет ведется только по записанным данным, новые кластеры, в которых очень мало или вообще нет виртуальных машин, могут показывать проценты накладных расходов, гораздо выше ожидаемых. Это связано с тем, что в кластере кроме стандартных, глобальных системных накладных расходов, практически нет других данных.

Результат

Этот конкретный пример демонстрирует, что ESA, даже после учета различных накладных расходов, может защищать данные с высоким уровнем устойчивости (FTT=2) таким образом, что практически все накладные расходы на отказоустойчивость и метаданные компенсируются. В этом примере на кластере, который предоставляет около 46 ТБ сырой емкости, было примерно 15 ТБ данных гостевых виртуальных машин, которые после учета накладных расходов и сжатия потребовали около 17,7 ТБ сырого хранилища. Предполагая тот же уровень сжатия для новых данных, можно было бы хранить еще 15 ТБ дополнительных данных в высокоустойчивом виде и оставаться в пределах базового порога операций для кластера в 38.27 ТБ.

По сравнению с OSA, ESA обеспечивает более высокую устойчивость (поскольку большинство клиентов используют менее устойчивый FTT=1 вместо FTT=2 на OSA), гораздо более высокую производительность и улучшенную эффективность использования пространства для снижения затрат. Intel недавно опубликовала материал, который подтверждает это мнение: "Beyond Savings:  How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!". И в отличие от традиционного модульного массива хранения, вы получаете полностью распределенную систему хранения, которую можно масштабировать постепенно и экономично, используя ваши любимые серверы.

Оценка требований к хранению данных

Как вы можете применить эти знания при планировании собственной среды? Утилита vSAN ReadyNode Sizer делает все расчеты необходимой емкости за вас. На рисунке ниже показано, что когда введены спецификации серверов и коэффициенты сжатия, чтобы они соответствовали этому кластеру, оценки емкости оказываются очень похожими.

Почти два года назад мы писали о решении Cloud Flex Storage, которое представляет собой распределенное хранилище и средства управления данными, полностью управляемые со стороны VMware. Это комбинация cloud-native абстракций, реализующих службы хранения для клиентов, которая предоставляет высокопроизводительные сервисы для современных нагрузок.

С помощью VMware Cloud Services Console пользователи могут масштабировать облачные хранилища без необходимости добавления дополнительных хостов и регулировать доступные емкости как вверх, так и вниз, для каждого из работающих приложений. Также здесь работает модель оплаты по мере потребления ресурсов (pay-as-you-go).

Когда VMware впервые представила Cloud Flex Storage на мероприятии VMware Explore 2022, основной целью было предоставить решение для управления данными и облачным хранилищем уровня предприятия. С тех пор компании разных размеров уже внедрили Cloud Flex Storage для легкого масштабирования хранилищ без добавления хостов, что для многих из них привело к значительной экономии средств. Теперь, с улучшениями, которые были представлены недавно, существенно расширен спектр поддерживаемых рабочих нагрузок, включая критически важные задачи. Основные направления развития продукта - это увеличение масштабируемости сервиса и укрепление его устойчивости.

Итак, давайте посмотрим, что нового:

1. Увеличенная масштабируемость: расширение объема облачного хранилища с эластичным ростом

В этом обновлении VMware Cloud Flex Storage теперь предоставляется дизагрегированное хранилище уровня петабайтов на платформе VMware Cloud on AWS. VMware удвоила доступную емкость на одном хранилище с 400 ТБ до 800 ТБ. Кроме того, теперь поддерживаются до 4 хранилищ на одном SDDC, что позволяет клиентам использовать до 3.2 петабайт хранилища в одном SDDC.

2. Повышение устойчивости: обеспечение производительности для критических приложений

Для поддержки более широкого спектра рабочих нагрузок, включая критически важные приложения, VMware существенно улучшила производительность операций чтения на Cloud Flex Storage. Это позволит клиентам VMware Cloud on AWS запускать больший набор приложений с обеспечением постоянной высокой производительности.

За подробностями о нововведениях технологии VMware Cloud Flex Storage вы можете обратиться к этой странице.

С выходом обновленной версии VMware vSAN 8 в этом решении появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

Дункан Эппинг в ответ на запрос пользователей решения vSAN ESA сделал интересный пост на тему минимально необходимого числа хостов, которое требуется для поддержания определенного уровня избыточности - RAID-0/1/5/6.

В VMware vSAN 8 Update 1 появился адаптивный алгоритм записи, который существенно уменьшает избыточность записи на RAID-конфигурации. Когда мы рассматриваем, куда записываются данные по умолчанию используя путь записи ESA для объекта, использующего erasure codes для RAID-6, это уменьшает избыточность записи данных с 4,5x (3x для тройного зеркала + 1,5x для полосы RAID-6 4+2 с двойной паритетной проверкой) до всего лишь 1,5x. Это не только сокращает объем вычислений в процессорах, но и уменьшает сетевой трафик. Этот новый адаптивный путь записи приводит к большему объему передачи данных для всех рабочих нагрузок, которые склонны генерировать большие размеры I/O или большое количество ожидающих операций, создавая ситуации, обычно называемые большим количеством необработанных операций ввода-вывода (high outstanding I/O).

Теперь для vSAN ESA на базе RAID-5, в зависимости от размера кластера, могут быть использованы конфигурации 2+1 или 4+1, а конфигурация 3+1 больше не поддерживается. При этом для RAID-1 и RAID-6 в конфигурациях ничего не изменилось.

Ну и, собственно, ниже приведена таблица, которая позволит вам понять, какое минимальное число хостов ESXi нужно использовать для каждой из выбранных конфигураций, и как это сказывается на дополнительных затратах дисковой емкости:

Когда мы рассказывали о нововведениях в продуктовой линейке VMware на 2024 год, мы упоминали, что компания в составе Broadcom решила полностью перейти на модель подписки на свои продукты (VMware Cloud Foundation и VMware vSphere Foundation), исключив "вечные" (perpetual) лицензии и поддержку. Также к этим продуктам можно докупать аддоны, которые лицензируются отдельно, в зависимости от типа аддона.

На днях VMware объявила об этом официально. Подробную информацию о данном переходе можно найти в KB 96168.

Кроме того, VMware от Broadcom также планирует предложить возможность использовать уже имеющиеся купленные лицензии в рамках программы Bring Your Own License, которая позволит клиентам получать новые подписки на VMware Cloud Foundation от Broadcom и гибко использовать эти подписки в проверенных гибридных облачных средах VMware, а также в собственных локальных датацентрах.

Еще одним результатом этого перехода является то, что продукты, перечисленные в таблице ниже, теперь находятся на стадии снятия с производства (End of Availability, EOA) в качестве отдельных продуктов. Некоторые предложения все еще могут быть доступны для использования в рамках решений VMware Cloud Foundation (VCF) или VMware vSphere Foundation (VVF), что отмечено отдельно.

VMware также объявляет об окончании доступности (EOA) услуг Aria SaaS, но продолжит поддерживать клиентов, в настоящее время использующих эти услуги, до конца срока их подписки. По истечении срока подписки клиентам нужно будет перейти на использование либо VCF, либо VVF. Также обратите внимание, что услуги Aria SaaS находятся в режиме maintenance mode, что означает, что новые функции не будут доступны, хотя обновления безопасности и критические обновления будут предоставляться в течение активного периода подписки.

Это объявление охватывает все варианты лицензирования, включая Perpetual, поддержку и подписку (Support & Subscription, SnS), SaaS/хостинг и другие типы подписок. Оно также касается каждого издания, пакета и модели ценообразования для каждого продукта. Любое исключение из этого правила будет указано отдельно.

Эта таблица позволит вам понять сущность перехода от старых продуктов на новые:

Обратите внимание, что бесплатного решения VMware ESXi (vSphere Hypervisor) больше нет! За все надо платить)

Если вы являетесь существующим клиентом и приобрели продукты, которые сейчас находятся на стадии окончания доступности (End of Availability), но ваша подписка пока не подлежит обновлению, в настоящее время никаких немедленных действий не требуется. VMware будет продолжать предоставлять активную поддержку на протяжении всего срока вашего договора поддержки. В будущем, в момент обновления подписки, вы можете работать со своим представителем или партнером VMware, чтобы согласовать ваши дальнейшие требования с обновленным портфелем предложений VMware.

Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

4. После этого начнется процесс апгрейда формата дисков, продолжительность которого зависит от размера вашей инфраструктуры и количества дисков:

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы:

На сайте VMware Developer появился полезный сценарий PowerCLI, который позволяет администратору изменить текущий контроллер SCSI на новый тип для виртуальной машины на платформе VMware vSphere.

Некоторые особенности работы этого сценария:

• Не проверяет, настроена ли виртуальная машина для 64-битной гостевой ОС (адаптер BusLogic не поддерживается)
• Ппроверяет, работают ли VMware Tools и выключает виртуальную машину с помощью функции выключения гостевой ОС
• Возвращает виртуальную машину в предыдущее рабочее состояние
• Проверяет, было ли уже установлено новое значение контроллера SCSI

Функция Modify-ScsiController вызывается в самом конце скрипта. Вот различные примеры того, как функция может быть использована:

Скачать данный сценарий можно по этой ссылке.

Дункан Эппинг написал интересную статью про обслуживание межсайтового соединения (ISL) растянутого кластера VMware vSAN. Обычно, если условия позволяют, можно потушить все рабочие нагрузки (ВМ) на обеих площадках, после чего можно выключить кластеры и проводить обслуживание сетевого линка между площадками. Эта процедура описана в KB 2142676.

Но что делать в случае, когда вам нужно, чтобы рабочие нагрузки на одной из площадок продолжили выполняться во время обслуживания ISL?

В VMware vSAN 7 Update 3 появился механизм vSAN Witness Resiliency, который мы подробно описывали в статье "Улучшения VMware vSAN 7.0 Update 3 - пересчет голосов для обеспечения кворума при последовательных отказах". Он позволяет сохранять кворум в кластере и его функционирование при последовательных отказах - сначала одного из датацентров, а потом и компонента Witness.

Этот механизм и можно использовать для обслуживания ISL-соединения. Итак, переводим все хосты кластера на сайте 1 в режим обслуживания (Maintenance Mode) или выключаем их. В этом случае в растянутом кластере голоса для компонента Witness будут пересчитаны в течение 3 минут. После этого можно выключить и сам Witness - и это не приведет к падению виртуальных машин на сайте 2.

Итак, как он это проверял. Сначала перевел все хосты сайта 1 в режим обслуживания - и все его виртуальные машины начали переезд на второй сайт.

Затем он проверил RVC-консоль (как мы писали выше) и дождался, пока за пару минут будут пересчитаны голоса. Далее он просто выключил компонент Witness, после чего он убедился, что все ВМ продолжили нормально работать на второй площадке:

После этого можно начинать обслуживание ISL-соединения и работы по улучшению межкластерного соединения.

Для верности можно выполнить команду vsan.vm_object_info в консоли RVC и проверить объекты/экземпляры виртуальных машин на предмет того, что они находятся в статусе "ACTIVE" вместо "ABSENT":

После завершения обслуживания ISL-линка, вы можете включить компонент Witness, после чего включаете обратно хосты сайта 1 и обязательно выполняете ресинхронизацию (resync). После этого механизм VMware DRS в автоматическом режиме сам сбалансирует нагрузки по площадкам, распределив их по ним с помощью vMotion.

Напомним, что в конце прошлого года в решении vSAN 8 появилась новая архитектура гиперконвергентной инфраструктуры Express Storage Architecture (ESA). Она позволяет достичь максимальных показателей производительности и эффективности на базе высокопроизводительных систем хранения.

С помощью флэш-памяти TLC на основе технологии NVMe, архитектура ESA имеет множество преимуществ со стандартной vSAN Original Storage Architecture (OSA), которая также продолжит поддерживаться для стандартного на текущий момент оборудования (устройства SATA/SAS).

Ранее мы рассказывали об объектах Storage Pools в vSAN ESA, а также о реализации механизмов повышенной производительности в VMware vSAN 8 Update 1. Ну а недавно компания VMware опубликовала интересное видео, в котором рассказывается о производительности vSAN ESA в сравнении с OSA:

Посмотрим на некоторые полезные скриншоты из видео. Улучшения производительности на уровне отдельного VMDK (RAID-6 ESA работает лучше, чем RAID-1 OSA):

Результаты теста SPEC - время отклика при увеличении числа операций в секунду:

Зависимость задержек (latency) от числа снапшотов на хранилище:

Также почитайте, как именно улучшения производительности VMware vSAN 8 Update 1 влияют на разные типы приложений.

Большинство администраторов уже знакомы с новой функциональностью, которая доступна в новой версии платформы виртуализации VMware vSphere 8 Update 2, о которой было объявлено в рамках конференции VMware Explore 2023. Сегодня мы поговорим об улучшених подсистемы работы с хранилищами (Core Storage).

vSphere 8 U2 содержит ряд важных нововведений, и область хранения данных не является исключением. Как вы, вероятно, заметили, VMware в последнее время делает акцент на технологиях vSAN, vVols и NVMeoF, и в этом году особое внимание уделяется vVols. В vSphere 8 было много важных усовершенствований. Например, новые спецификации VASA для vVols, улучшенная производительность и надежность, расширенное управление сертификатами и поддержка NVMeoF - и это лишь некоторые из них.

Хотя в vSphere 8 Update 2 и нет большого количества новых функций хранения, тем не менее, имеются некоторые важные обновления. vVols, NVMeoF, VMFS и NFS получили улучшения и функции, которые оценят многие администраторы.

Улучшения vVols

• Расширение Online Shared Disks для vVols

В релизе vSphere 6.7 была добавлена поддержка постоянных резерваций SCSI3-Persistent Reservations для vVols. Эта функция позволяет приложениям для кластеризации контролировать блокировку общих дисков. Примером приложения, требующего SCSI3-PR для общих дисков в кластере, является Microsoft WSFC.

Однако одной из последних функций, которые были у RDM, но не у vVols, была возможность расширять общий диск в онлайн-режиме в некоторых приложениях, таких как Microsoft WSFC. Теперь же и vVols поддерживает горячее расширение общих дисков с использованием постоянных резерваций SCSI3. Это позволяет расширять общие диски без необходимости выключать кластер приложений. Теперь у RDM нет преимуществ перед vVols. Администраторы могут мигрировать свои приложения MS WSFC на vVols и избавиться от RDM. Это значительно упрощает управление виртуальным хранилищем, снижает сложность и при этом сохраняет функции, основанные на массивах.

Кликните на картинку для просмотра анимации этого процесса:

• Поддержка онлайн-расширения диска vVols с Oracle RAC

В этом релизе, помимо MS WSFC, была добавлена поддержка горячего расширения и для дисков Oracle RAC с использованием режима Multi-Writer. Для расширения кластерных дисков теперь не требуется простоя. Это можно выполнять как на дисках SCSI, так и NVMe vVols. Это также позволяет клиентам мигрировать с томов RDM.

• In-band миграция томов vVols

Теперь доступна поддержка миграции пространств имен NVMe vVol внутри групп ANA. Эта функциональность обеспечивает эквивалентность примитиву перепривязки SCSI и позволяет администратору хранилища балансировать нагрузку ввода-вывода по объектам Protocol Endpoint (PE).

• Автоматическое восстановление из состояния PDL для PE vVol

Ранее, когда PE переходил в состояние PDL и затем возвращался, стек PSA должен был перезапустить устройство (уничтожить и снова обнаружить пути). Это могло произойти только после закрытия объектов vVol, использующих PE. В этом релизе, ВМ будут автоматически завершены в случаях, когда мы обнаруживаем, что PE, к которому привязаны vVols ВМ, находится в PDL. Это дополнительно повышает устойчивость и восстановление при определенных типах сбоев подсистемы хранения.

• Поддержка 3rd party MPP для NVMe vVols

Позволяет MPP (политике многопутевого доступа) от сторонних разработчиков поддерживать NVMe vVols. Это дает возможность партнерам VMware использовать свою клиентскую политику MPP.

• Поддержка UNMAP для конфигурационного vVol

Начиная с vSphere 8.0 U1, конфигурационные vVols теперь создаются как тонкие диски с максимальным размером 255 ГБ и форматируются с использованием VMFS-6. В этом релизе есть поддержка esxcli для выполнения процедуры unmap для конфигурационных vVols.

Улучшения NVMeoF

• Поддержка типа контроллера vNVMe для MS WSFC

В vSphere 7 был добавлен новый контроллер виртуальных машин - vNVMe, но изначально он не поддерживался для использования с WSFC. В vSphere 8 была добавлена поддержка кластеризованных приложений на хранилищах данных NVMeoF. В vSphere 8 U2 техническая команда VMware сертифицировала контроллер vNVMe для использования с Microsoft WSFC. Теперь вы можете использовать NVMe с полной поддержкой для приложений WSFC. Изначально это поддерживается только с SCSI vVols.

• Поддержка кластеризации Oracle RAC с vVols NVMe (FC, TCP)

Была добавлена поддержка кластеризованных дисков Oracle RAC vVol, размещаемых на бэкенде NVMe. Это включает NVMe-FC vVols и NVMe-TCP vVols.

• Включение поддержки vNVMe с Oracle RAC (vVols)

Была добавлена поддержка использования контроллера vNVMe в качестве фронтенда для кластеризации в режиме multi-writer (Oracle RAC).

Улучшения VMFS

• Улучшена производительность офлайн-консолидации снапшотов SE Sparse.

Производительность офлайн-консолидации снапшотов SE Sparse в этом релизе улучшена в несколько раз. Это помогает улучшить RPO и RTO для клиентов, использующих офлайн-консолидацию для целей восстановления после сбоев (DR).

Улучшения NFS

• Кэш DNLC для NFS4.1

В некоторых средах, использующих NFS4.1, имеются большие хранилища данных с сотнями ВМ, где поиск, включение или вывод списка ВМ могут быть медленнее, чем в NFSv3. Кэш поиска имен каталогов (DNLC) предназначен для уменьшения количества операций NFS LOOKUP за счет кэширования некоторых этих данных. В этом релизе была добавлена поддержка DNLC для NFS4.1. Это принесет пользу операциям, таким как "ls" в каталоге с большим количеством ВМ или файлов в хранилище данных.

• nConnect

В vSphere 8.0 U1 появилась поддержка nConnect, которая позволяет добавлять несколько соединений к хранилищу данных NFSv3. Это может помочь снизить задержку и увеличить производительность. В Update 2 появилась поддержка динамического увеличения и уменьшения количества соединений, используемых с nConnect. В настоящее время это настраивается только через esxcli.

В ноябре компания VMware выпустила обновление продукта Aria Automation November 2023, предназначенного для автоматизации операций виртуальной инфраструктуры VMware vSphere. Ранее мы рассказывали о нововведениях этого решения в плане функций управления в публичных облаках.

В этом выпуске было объявлено о расширении плагин-ориентированного фреймворка для поддержки облачных ресурсов Azure в рамках шаблонов Aria Automation Templates для развертывания вычислительных мощностей, сетей, дисков, storage-аккаунтов и ресурсов баз данных SQL Azure. Использование элементов шаблонов на основе плагинов позволяет клиентам легко получать доступ к ресурсам публичного облака и их свойствам в точном соответствии с определениями вендора.

В этом релизе Aria Automation поддерживает все три крупнейших облачных провайдера: AWS, GCP и Azure. VMware планирует продолжать поддерживать больше типов ресурсов на основе плагинов в будущих ежемесячных релизах.

Еще одной важной функцией является VMware Aria Automation for Secure Hosts, которая теперь предоставляет действия по предварительному и пост-устранению уязвимостей.

Пользователи теперь могут использовать файлы состояний Salt в файловом менеджере, чтобы указать предварительное состояние перед началом исправления уязвимостей. Кроме того, можно установить необязательное пост-состояние для действий после завершения ремедиации. Это улучшение экономит время администраторам ИТ, автоматизируя задачи по предварительной и пост-ремедиации.

Помимо отмеченных выше новых функций, появились следующие улучшения пользовательского опыта в VMware Aria Automation:

1. Дополнительное предупреждение для Day-2 действия Resize

Теперь действие изменения размера дополнено предупреждением о том, что если функция Hot Add не включена в vCenter, машина будет перезагружена и не будет работать в это время. Когда горячее добавление включено, пользователи могут выбрать, перезагружать ли машину или нет при изменении, причем "не перезагружать" установлено по умолчанию.

2. Поддержка онпремизного SCM (GitLab Enterprise) в VMware Aria Automation SaaS

Эта функция позволяет администраторам настроить GitLab Enterprise как эндпоинт для репозитория. Шаблоны VMware Aria Automation, скрипты Terraform и сервисы ABX могут быть импортированы из GitLab Enterprise. Это расширение сервиса VMware Aria Automation SaaS клиенты могут использовать как в локальных, так и в SaaS-средах.

3. Поддержка свойств OVF в vCenter Content Library

Теперь поддерживается указание свойств для пакетов OVF/OVA, хранящихся в библиотеке содержимого vCenter, в шаблонах VMware Aria Automation с использованием свойства 'ovfProperties:', доступного в элементе vSphere Machine. Шаблоны OVF/OVA, созданные в кластере vSphere или хранящиеся в библиотеке содержимого vCenter, отображаются в сопоставлениях образов в VMware Aria Automation Assembler.

4. Улучшения плагина Infoblox IPAM

Версия 1.5.1 плагина VMware Infoblox для VMware Aria Automation вносит несколько улучшений, таких как повышение удобства использования, устранение false positives и повышение безопасности за счет использования OpenSSL 3.0.x, Photon 4.x и Python 3.10.11 в качестве среды выполнения ABX. Подробнее об этом тут.

Более подробно о новых возможностях VMware Aria Automation November 2023 вы можете узнать из Release Notes.

В рамках проходившей недавно конференции Explore 2023 Europe компания VMware анонсировала релиз новой версии своего основного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 13.2. Напомним, что о прошлой версии этого пакета - PowerCLI 13.1 - мы писали вот тут.

Этот релиз предоставляет официальную поддержку VMware Cloud Foundation (VCF) в PowerCLI, а также новые функции для vSphere, vSAN и VMware Cloud.

1. Новые SDK-модули для VCF

VMware Cloud Foundation (VCF) - это интегрированная платформа, объединяющая полный спектр программно-определяемых сервисов в единую систему. По мере того, как все больше клиентов VMware начинают использовать VCF, увеличивается и спрос на автоматизацию через CLI. До сих пор единственным вариантом был модуль PowerVCF с открытым исходным кодом, но с PowerCLI 13.2 было добавлено два официальных модуля VCF – VMware.Sdk.Vcf.CloudBuilder и VMware.Sdk.Vcf.SddcManager. Это SDK-модули, использующие ту же технологию, что и модули PowerCLI SDK для vSphere Automation, NSX, SRM и API vSphere Replication. Как и в случае со всеми SDK-модулями, примеры PowerCLI можно найти непосредственно в документации REST API для VCF.

2. Новые функции управления жизненным циклом vSphere

В PowerCLI 13.2 было добавлено два новых командлета для vLCM:

• Export-LcmVMHostDesiredState экспортирует желаемое состояние хоста vSphere Lifecycle Manager
• New-OfflineBundle создает автономный пакет, соответствующий требованиям vLCM, на основе введенных данных о хранилищах и спецификации программного обеспечения.

3. Новые функции vSAN

В PowerCLI 13.2 был добавлен новый командлет Get-VsanPerformanceContributor в модуль VMware.VimAutomation.Storage. Он позволяет получить список наиболее значимых объектов, влияющих на производительность vSAN. Также был расширен вывод командлета Get-VsanSpaceUsage за счет свойства EsaObjectOverheadGB, которое предоставляет информацию о дополнительных накладных расходах для объектов vSAN ESA на хранение метаданных и обеспечение высокой производительности.

4. Новые функции VMware Cloud

В PowerCLI 13.2 были расширены командлеты New-VmcSddc и New-VmcSddcCluster за счет добавления поддержки хостов I4I.

5. Обновленные SDK-модули

В PowerCLI 13.2 были обновлены все модули, предоставляющие привязки к API. А именно:

• Модули vSphere обновлены до версии vSphere 8.0 Update 2
• Модули NSX обновлены до версии NSX 4.1.2
• Модули SRM и vSphere Replication обновлены до версии 8.8
• Модуль Horizon обновлен до VMware Horizon 8 2306

Скачать последнюю версию фреймворка VMware PowerCLI 13.2 можно по этой ссылке.

В июне этого года компания VMware представила большое обновление архитектуры VMware Cloud Foundation 5.0 (VCF), в котором был полностью обновлен BOM (bill of materials), а также добавлено множество новых возможностей по управлению гиперконвергентной виртуальной средой. В рамках проходящей сейчас конференции Explore 2023 Europe было представлено очередное обновление VMware Cloud Foundation 5.1.

Давайте посмотрим, что нового появилось в VCF 5.1:

Поддержка VCF для архитектуры vSAN Express Storage (ESA)

В новой версии VCF появилась расширенная поддержка платформ хранения NVMe с поддержкой архитектуры vSAN Express Storage (ESA), которая позволяет клиентам развертывать серверы следующего поколения, обеспечивающие повышенную производительность, большую масштабируемость и улучшенную эффективность. Работая в сочетании с оригинальной архитектурой хранения vSAN (OSA), vSAN ESA представляет собой архитектуру, разработанную для достижения совершенно новых уровней эффективности, масштабируемости и производительности, оптимизированную для использования полного потенциала самого современного оборудования. Подробнее о vSAN ESA вы можете узнать вот тут.

Улучшения в области сетей и безопасности

Релиз VCF 5.1 содержит несколько улучшений, которые упрощают настройку расширенных сетевых функций подсистемы безопасности. Самое значительное изменение — это улучшенные рабочие процессы SDDC Manager, которые позволяют администраторам настраивать новые домены рабочих нагрузок и кластеры с несколькими физическими сетевыми адаптерами и виртуальными распределенными коммутаторами, подготовленными для NSX.

Были внесены и другие улучшения сетевой инфраструктуры, которые дополнительно используют NSX, с упрощенной и соответствующей стандартам топологией для расширенных кластеров, настроенных для vSAN OSA, и возможностью настройки Edge-кластеров без двухуровневой маршрутизации.

Эти улучшения глубокого тюнинга сети позволяют администраторам обеспечивать высокопроизводительные сетевые топологии с повышенной безопасностью, которые могут быть легко масштабированы и управляемы в течение всего жизненного цикла.

Распределенный движок сервисов vSphere для сред VCF

Релиз VCF 5.1 также поддерживает распределенный движок сервисов vSphere (ранее известный как Project Monterey), позволяющий оборудованию специализированной обработки данных (DPU) исполнять задачи, которые традиционно выполнялись гипервизором на процессорах x86. Вынесение туда задач, таких как сетевое взаимодействие и безопасность, на эти программируемые аппаратные ускорители, позволяет повысить общую производительность и поддержку более требовательных к производительности рабочих нагрузок. Первоначальная поддержка позволяет клиентам выгружать стек виртуализации NSX, работающий на хосте, в шину PCIe устройств SmartNIC, улучшая производительность и освобождая циклы процессора. В VCF 5.1 поддерживаются DPU от AMD и NVIDIA.

Улучшения GPU для производительности и масштабируемости

Для поддержки больших рабочих нагрузок генеративного ИИ и LLM (больших языковых моделей), среды, использующие GPU NVIDIA, могут использовать динамический DirectPath I/O (также называемый "passthrough") или конфигурации NVIDIA vGPU. Это поддерживает множество сценариев использования и позволяет обеспечивать максимальную производительность до 16 GPU/vGPU на одну виртуальную машину, что удваивает возможности GPU по сравнению с предыдущими версиями VMware Cloud Foundation. Использование одного или нескольких профилей NVIDIA vGPU на ваших виртуальных машинах обеспечивает большую интеграцию с инфраструктурой VMware за счет поддержки продвинутых возможностей vSphere, таких как vMotion, размещение ВМ с DRS и опций для более эффективной упаковки меньших ВМ с vGPU, в ваши кластеры для освобождения места для более крупных GPU-нагрузок, таких как LLM.

Другие ключевые улучшения, доступные в VMware Cloud Foundation 5.1

• Интеграция управления жизненным циклом облачных систем с VMware Aria Suite
• Обновления управления жизненным циклом, включая асинхронные предварительные проверки и поддержку образов vSphere Lifecycle Manager в управляющих доменах VCF.
• Многочисленные улучшения сетевой инфраструктуры для растянутых кластеров vSAN, кластеров NSX Edge и усовершенствованных рабочих процессов SDDC Manager.
• Служба VMware Identity Broker позволяет администраторам подключаться к сторонним/внешним провайдерам идентификации (IDP) для обработки учетных данных и аутентификации (включая многофакторную аутентификацию). Теперь OKTA поддерживается как сторонний брокер в средах VMware Cloud Foundation.
• Новый провайдер Terraform для VMware Cloud Foundation, который позволяет использовать инфраструктуру как код для развертывания, управления и обслуживания VMware Cloud Foundation с помощью машиночитаемых файлов определений для достижения заданного состояния.

VMware Cloud Foundation 5.1 теперь доступен для постоянного развертывания, среды на базе подписки будут поддерживаться в VCF 5.1 на более позднем этапе.

Подробнее об инфраструктуре VCF вы можете узнать на странице продукта. Технические ресурсы по платформе доступны тут.